Un buen entorno de logging te permite depurar y entender qu\u00e9 est\u00e1 pasando en tu simulaci\u00f3n, as\u00ed como entender c\u00f3mo est\u00e1 estructurado el simulador NS3 y sus diferentes m\u00f3dulos.
\nEl sistema de logging de NS3 se usa mediante variables de entorno y mediante el propio c\u00f3digo de tu simulaci\u00f3n si quieres habilitar logging en tu propia simulaci\u00f3n.<\/p>\n
Se establecen siete niveles de log proporcionando de menos a mas informaci\u00f3n:<\/p>\n
Adicionalmente hay un nivel incondicional que imprime la salida con independencia de los niveles de log activos o no. Este es NS_LOG_UNCOND Es buena idea usar el mecanismo de log en cualquier simulaci\u00f3n de ns3 pero se hace imprescindible si aspiras a crear un nuevo m\u00f3dulo para el simulador destinado a ser usado por la comunidad.<\/p>\n","protected":false},"excerpt":{"rendered":" Un buen entorno de logging te permite depurar y entender qu\u00e9 est\u00e1 pasando en tu simulaci\u00f3n, as\u00ed como entender c\u00f3mo est\u00e1 estructurado el simulador NS3 y sus diferentes m\u00f3dulos. El sistema de logging de NS3 se usa mediante variables de … Sigue leyendo
\n\u00bfC\u00f3mo visualizamos la informaci\u00f3n de log en ns3?, bien, vamos a comenzar con nuestro ejemplo IoT b\u00e1sico donde, precisamente, uno de los problemas es que no gener\u00e1bamos ning\u00fan tipo de informaci\u00f3n acerca de la simulaci\u00f3n.
\nEfectivamente si lo ejecutamos, habiendo colocado previamente el archivo basic-iot-sensors.cc en el directorio scratch:
\n
\n$.\/waf --run basic-iot-sensors
\nWaf: Entering directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nWaf: Leaving directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nBuild commands will be stored in build\/compile_commands.json
\n'build' finished successfully (2.047s)
\n<\/code>
\nVemos que no sale ning\u00fan tipo de informaci\u00f3n \u00fatil acerca de la simulaci\u00f3n salvo que se ha compilado y ejecutado sin errores.
\nVamos a estudiar la informaci\u00f3n que nos genera el m\u00f3dulo de YansWifiPhy, para ello:
\n
\n$ export NS_LOG=YansWifiPhy
\nfelix@homer:~\/tools\/ns-allinone-3.30.1\/ns-3.30.1$ .\/waf --run basic-iot-sensors
\nWaf: Entering directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nWaf: Leaving directory `\/\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nBuild commands will be stored in build\/compile_commands.json
\n'build' finished successfully (1.701s)
\n+0.000000000s -1 YansWifiPhy:YansWifiPhy(0x5641614960f0)
\n+0.000000000s -1 YansWifiPhy:SetChannel(0x5641614960f0, 0x564161490400)
\n+0.000000000s -1 YansWifiPhy:YansWifiPhy(0x56416153d640)
\n+0.000000000s -1 YansWifiPhy:SetChannel(0x56416153d640, 0x564161490400)
\n+0.000000000s -1 YansWifiPhy:YansWifiPhy(0x564161541e90)
\n...
\n<\/code>
\nvemos que usamos la variable de entorno NS_LOG para fijar el m\u00f3dulo en el que estamos interesados. Si ponemos NS_LOG a un nombre de un m\u00f3dulo que no existe se imprimir\u00e1 un listado de todos los m\u00f3dulos que NS3 tiene implementados. El nivel de log por defecto en la mayor\u00eda de los m\u00f3dulos ser\u00e1 todos, podemos especificarlo tambi\u00e9n a la hora de definir el m\u00f3dulo. Por ejemplo vamos a definir el nivel info para el m\u00f3dulo UdpClient:
\n
\n$ export NS_LOG=UdpClient=level_info
\n$ .\/waf --run basic-iot-sensors
\nWaf: Entering directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nWaf: Leaving directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nBuild commands will be stored in build\/compile_commands.json
\n'build' finished successfully (1.480s)
\nTraceDelay TX 32 bytes to 10.1.1.1 Uid: 0 Time: 2
\nTraceDelay TX 32 bytes to 10.1.1.1 Uid: 1 Time: 2
\nTraceDelay TX 32 bytes to 10.1.1.1 Uid: 2 Time: 2
\nTraceDelay TX 32 bytes to 10.1.1.1 Uid: 33 Time: 2.5
\n....
\n<\/code>
\nVemos que ahora sale la informaci\u00f3n de las aplicaciones UDP instaladas en los nodos IoT enviando informaci\u00f3n. Substituye level_info por level_all en el primer comando para que veas como sale mucha m\u00e1s informaci\u00f3n.
\nSi alg\u00fan m\u00f3dulo no se usa en t\u00fa simulaci\u00f3n y pones NS_LOG a ese m\u00f3dulo no saldr\u00e1 ninguna informaci\u00f3n adicional.
\nSi quieres indicar que el nombre de la funci\u00f3n que genera el mensaje tambi\u00e9n se imprima, puedes hacer un OR con prefix_fund. En bash necesitar\u00e1s comillas:
\n
\n$export 'NS_LOG=UdpClient=level_all|prefix_func'
\n<\/code>
\nPara habilitar varios m\u00f3dulos, puedes encadenar usando : varios m\u00f3dulos.
\n
\n$ export 'NS_LOG=UdpClient:UdpServer'
\n<\/code>
\nVamos a crear un m\u00f3dulo para nuestra simulaci\u00f3n y a sacar nuestro mensaje de log. Para ello, edita el archivo basic-iot-sensors.cc y a\u00f1ade estas dos l\u00edneas, por ejemplo, justo debajo de donde se inicia la funci\u00f3n main:
\n
\nint main (int argc, char *argv[]){
\nNS_LOG_COMPONENT_DEFINE (\"IotEjemplo\");
\nNS_LOG_INFO (\"Creando la simulaci\u00f3n\");
\n<\/code>
\nAunque ya estaba incluido en dicho archivo, si lo utilizas en tu simulaci\u00f3n acuerdate incluir los archivos de cabezera de log (\u00abns3\/log.h\u00bb).
\nEn la primera funci\u00f3n definimos el m\u00f3dulo IotEjemplo y en la segunda sacamos nuestro primer mensaje. Si ahora queremos ver esa informaci\u00f3n:
\n
\n$export 'NS_LOG=IotEjemplo'
\n$ .\/waf --run basic-iot-sensors
\nWaf: Entering directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\n[2876\/2963] Compiling scratch\/basic-iot-sensors.cc
\n[2921\/2963] Linking build\/scratch\/basic-iot-sensors
\nWaf: Leaving directory `\/ns-allinone-3.30.1\/ns-3.30.1\/build'
\nBuild commands will be stored in build\/compile_commands.json
\n'build' finished successfully (6.339s)
\nIotEjemplo:main(): [INFO ] Creando la simulaci\u00f3n
\n<\/code>
\nDonde, como podemos ver, se muestra nuestro mensaje.<\/p>\n