I’ve almost finished the module (read: compilation reports no error) and
take some time to discuss about some potential issues.
- Interaction with Nginx
I try to not affect Nginx but some files need to be modified since this
offer a very simple API to other modules, so there are two paths:
module but activated or not by the config file or conditional
believe conditional compilation is the norm but please let me know.
To access the shared memory I want to create a file: nginx.monitoring at
same location as nginx.pid. Then a ftok() on this file to get the System
and another process would be able to attach to the shared memory. But as
Linux guy I don’t know if *BSD, Mac-OSX and Solaris would be OK with
know too if all scripting languages can use System V calls.
So far I think it is clean but if you have a suggestion better you’re
The API consist in one call:
void ngx_register_monitoring_value (ngx_str_t * name, ngx_atomic_t *
This function should be called by an Nginx module during it’s
tell the monitoring module that this variable should be added to the
That’s all. The module just continue to do what it wants with its
value, I will do the rest.
I may have some issue because my module has three states: initializing,
registering, running so may be the order of modules may be problematic.
At top level just put ‘monitoring ;’. But some modules offering
variables to be
monitored may propose configuration options like:
monitor_timeout_counter on ;
and call or not ngx_register_monitoring_value() according to the
A script should have read access to where nginx.pid is and will do the
shm_id = ftok (“path.to.nginx.monitoring”) ;
mem = attach_to_shared_mem (shm_id) ;
values = parse (mem)
for example: update RRD databases, search for an anormal error count,
an event unexpected…
It’s no more my problem
Dear List, tell me what you think and I will release soon this module
BSD-like licence of course) for review and comments.