Tag Archive for 'git'

News from Core, CGIs & IDOUtils – Part III

Now that you have read about IDOUtils and the CGIs, it is time for the big one :-)

Icinga Core

All changes, fixes and enhancements do not affect compatibility to Nagios ™ – you’ll just get more fixes and enhancements if you decide to move over to Icinga.

The list of fixes and code improvements is rather long thanks to Andreas Ericsson who is working on his own Nagios ™ development branches. All those recent commits have been reworked into Icinga Core (if not already done). There were some nifty patches making developers life more easy and the source code a bit more readable and reusable.

Furthermore protection against typos in macro names has been added next to missing  NOTIFICATIONISESCALATED macro.  Performance data files are now closed correctly and the pipes are also set properly on configuration re-read.

SIGSEGV in checks on Solaris have been fixed thanks to Thorsten Huebler. There are also some other fixes for Solaris which are currently in development (thanks Alexander Skwar).

The fix by Ton Voon for choosing next valid time on day of DST change when clocks go one hour backwards is also in 1.0.2.

Next to that Ton Voon provided the in sync retention facility on the core by Opsera Ltd which has been reworked into Icinga – we think this might be useful.  Also, there was a Nagios ™ patch for adding new is_volatile setting of 2 for services, which respects the re-notification interval for notifications which also can be found applied and tested in Icinga Core.

There was a bug removing comments – now it is fixed and removing one comment will not remove all of them.

Scheduling a downtime for all services and the host now works as expected. Also custom notifications are not sent anymore during downtimes (thanks Sven Nierlein).  notification_period inheritance for services has been fixed using a patch by Gordon Messmer.

Notifications not being sent out when scheduled downtime is cancelled is also fixed next to the fix for first notification delay being calculated incorrectly causing notifications potentially going out early.

The initscript has been slightly reworked in order to show config errors as an own option. Furthermore the output is saved into a file which will can be looked up after a normal start. The initscript also does not remove the pid file anymore if Icinga did not stop in a timely manner. If a lockfile without running PID is found during startup, it will be removed instead of bailing out.

Starting the Core now throws an error if contactgroups are not matching. This happens now too if a service description is missing on a service object definition (if defined in used template there won’t be an error!).

Servicechecks with timeperiods containing ‘exclude’ directives are now correctly re-scheduled – this is noted in Nagios ™ Changelog for 3.4 and will be fixed in Icinga 1.0.2.

Steven D. Morrey implemented a patch for an extended scheduling queue which has been slightly reworked and improved for Icinga. The -S option functions much like -s but will dump the entire scheduling queue is it would run, in addition to providing the summary data.

Steven also created another patch long time ago – adding an event profiling option for stats of event counts and time taken for events. We integrated that as a config option in icinga.cfg and took the chance to add those stats to the current CGIs in ‘Performance Info’ – in case the option is enabled of course.

We finally implemented the state-based escalation ranges feature by Mark Gius: “The directives first_notification and last_notification apply to the total count of notifications on a particular service or host. It is sometimes desirable to escalate after the Nth critical notification, rather than after a total number of N notifications have been sent.”

Max Schubert’s patch to add enhanced diagnostic output when a regular expression fails to compile also has been added to Icinga.

There have been questions about another syslog facility – Icinga can now send log messages to syslogd using a local facility instead of the default one.  If enabled you can chose between 0 to 7.

Currently Icinga uses popen and system to run active check commands with shell intepretation. If using execv instead so there won’t be no shell expansion required. This means that 1 less process (sh) is required to execute an active check, which should give a performance improvement. When running the active check, check if there are any shell metacharacters. If there are, fallback to the shell invocation. Otherwise use the new execv method.

We had a speedup of parsing status.dat a while ago, now Matthieu Kermagoret provided another patch for minimizing loading time of the retention file. From his reports, they used  a standard setup with 1500 hosts, 19000 services and around 80 000 comments – before the restart took 20 minutes. Having the patch applied, only 2.6 seconds (!).

Icinga Core, CGIs & IDOUtils fit perfectly together with Docs, the API and the new Web. Please help us test for the upcoming release on 30.6.2010 (counter is GMT+1) and report issues !!! :-)

Interested in Icinga development and (re-)implement features and resolve performance issues? – Then please get in touch:

* Mailinglists

* IRC: irc.freenode.net #icinga #icinga-devel

* Icinga Portal

* Twitter

  • Share/Bookmark

Icinga IDOUtils – More Improvements Part III

One last shot this time for upcoming Icinga 1.0.1 and IDOUtils:

After getting several core patches into the master and also fixing duplicated service/hoststatus updates being sent to the neb module (thanks to Matthieu Kermagoret) there will be more improvements for IDOUtils.

Since the threaded housekeeper is doing fine, it is possible to periodically clean more tables. By popular demand, the following options have been added to ido2db.cfg

They can be used for your likings, by default they are not set.

If you want to help us test for the upcoming release, you are very welcome to do so!

To help you with GIT, we now have a quite detailed tutorial how to use GIT based on Icinga in our Developer Wiki =)

  • Share/Bookmark

Icinga IDOUtils – More improvements Part I

It’s been a while since I made several changes to the initial Oracle implementation in Icinga IDOUtils. Code has been split, first start of using prepared statements and binded params with ocilib and some other changes to the code.

In the last few weeks I have been investigating a lot on how to implement more improvements and optimize the critical path of data input from Icinga Core.

I want to start with IDOUtils Oracle, more information on other improvements for Icinga and IDOUtils will follow :)

Oracle implementation splits up into several parts taken care of:

  • Rewrite all queries to prepared statements and bind params at runtime
  • Add dynamic procedures for DELETE statements
  • Drop autoincrement emulation by one sequence and insert triggers
  • Add sequences for each table and use INSERT INTO … (id, …) VALUES (seq_name.nextval, …)
  • Add RETURNING id INTO :id for INSERT statements to save one round trip
  • MERGE does not support returning INTO, added SELECT seq_name.currval query instead for fetching last inserted id
  • Rewrite selecting cached objects from DB

The rewritten queries are divided as follows:

  • 1x SELECT latest data time as is (called only at startup)
  • dynamic procedure for DELETE on table by instance_id called at startup for cleaning config/status
  • dynamic procedure for DELETE on tably by instance_id, field compared to time called during periodic cleanup
  • all other queries are prepared with their own statement handler
    • 4x DELETE
    • 52x MERGE
    • 9x INSERT
    • 9x UPDATE
    • 5x SELECT

This summarizes into about 8000 lines (+) and 2000 lines (-) of code modifications :-)

Furthermore I have been thinking on how to provide an upgrade path for all existing IDOUtils Oracle users. Importing data using the newly applied sequences might lead into errors regarding currval of each sequence. A basic upgrade procedure has been provided already – if you want to try, get the latest GIT master.

Stay tuned for more interesting stories to tell :)

… and watch out for Icinga 1.0.1 and fresh IDOUtils Oracle!

  • Share/Bookmark

Icinga development visualized by Gource

Hi there,

Icinga and the fork happened not that long ago but during this period of time a lot of nice things happened.

Providing Icinga Core with integrated IDOUtils supporting MySQL/Postgres/Oracle, fresh docbook format and therefore enhanced documentation, a completely new Icinga API based on IDOUtils and providing data for the new upcoming Icinga Web. Also lots of other improvements and enhancements.

Writing a historical overview would get boring soon. So we decided to catch up on another Idea: gource.

It’s a small program fetching all commits within our git repositories (core, doc, api, web) and presenting the timeline and changes using rendered pictures.

But that’s not all, it is possible to convert that to nice looking movies.

But there is so much to tell…

Not this time!

Just relax and watch :-)

Icinga Core

Icinga Doc

Icinga API

Icinga Web

  • Share/Bookmark

Fixes for Icinga IDOUtils MySQL

Hi there,

just wanted to give you some updates regarding several fixes for Icinga IDOUtils. There were reports about doubled rows within several tables, where data only gets inserted and not updated. During my analysis it came up that there are several mistaken unique constraint definitions within the table creation for MySQL.

The unique constraint makes sure that if an INSERT will try to insert updated data, that this will create an internal exception which is caught within the ON DUPLICATE KEY clause. If caught, an UPDATE will be issued and everything is fine.

Regarding the table servicecheck, this was missing. So the start time of the servicecheck was inserted to the database, and when the servicecheck was complete, the end time also was inserted as own row into the database. Kind of useless 2 rows isn’t it? ;-)

Today i did some further investigations on that since this happened with systemcommands too. It came up that tables timedevents and timedeventqueue had that “feature” too.

This is really bad because there are lots of those queries issued and data will grow fast. Not this time because there has been another modification to idomod.cfg – the data processing options haven been modified to ignore timedevents by default. It will improve IDOUtils a bit, but your feedback is as always very welcome!

Back to topic – those missing unique constraints have been added to actual GIT Master (fixing #173 and #181 – check for analysis and comparison) so make sure you get the latest and the greatest! :-)

For those who are using Postgresql or Oracle – I have implemented and debugged them in deep. And they have own WHERE clauses for UPDATE – so no worries about that, everything is fine! =)

  • Share/Bookmark

Playing with Oracle, ocilib and parameter bindings

Hi there,

IDOUtils queries differ quite a lot – some of the are just executed during startup, while others happen all the time. By analyzing the performance on our Oracle database with grid  it came to the top queries just like for

  • servicechecks, servicestatus
  • hostchecks, hoststatus
  • timedevents
  • programstatus

But how to improve the performance of those queries when they are called all the time?

Well, the query as is is always the same, only the values happen to change. So the basic idea is to prepare the statements with value place holders and if it comes to the query, just to bind the paramaters (values) to the prepared statement and execute that. This is a real performance boost compared to putting the query within the rdbm cache all the time.

Generally speaking the query statements are prepared after database connection and the statement handle is stored within the global dbinfo object (where the connection handler resides too).

dbinfo.oci_statement_programstatus = OCI_StatementCreate(dbinfo.oci_connection);
OCI_Prepare(dbinfo.oci_statement_programstatus, MT("MERGE INTO table USING DUAL ON (v1=:X1) WHEN MATCHED THEN UPDATE SET v2=:X2 WHEN NOT MATCHED THEN INSERT (v1, v2) VALUES (:X1, :X2)"))

When a query should be executed, all values will be binded (X1, X2) to the statement.

OCI_BindUnsignedBigInt(dbinfo.oci_statement_programstatus, MT(":X1"), (big_uint *) value1)
OCI_BindString(dbinfo.oci_statement_programstatus, MT(":X2"), (char *) value2)

Then the query gets executed.

OCI_Execute(dbinfo.oci_statement_programstatus);

Well it sounds quite simple but regarding the architecture of *DOUtils it was a hard nut to crack. The most common problem was the query buffer building – each unixtimestamp conversion is done before query building and sending the query. That does not fit for prepared statements where the whole query is pushed into the database cache.

Within the code, there is an char* array which gets the SQL-code from ndo2db_db_timet_to_sql and this is then printed to the whole statements. Not very useful since you may paste that right within each query. For the prepared statements, I’ve added all plain unixtimestamps to the data[] array and then binding the values directly.

(SELECT unixts2date(:X3) FROM DUAL)

So the bind param task has been done for the initial steps, improved delete statements and other improvements need to be implemented.

Another thing which was quite nasty is that Oracle support was dependant on libdbi, but it was not even used. So I decided to split the code completely and change configure. If you use –enable-oracle it will only require ocilib to work, it does not complain about a missing libdbi. The other way around it also works fine just like it was.

Conclusion to that – you won’t need libdbi to get Oracle support for Icinga IDOUtils – just ocilib.

Those improvements have been pushed to actual GIT master und you are very welcome to test and report bugs! =)

  • Share/Bookmark

Icinga IDOUtils will support Oracle RDBM in 1.0 RC

Hi there,

work was not getting better and getting Oracle to work was on hold. So I decided to push a night of coding after I had prepared the MERGE queries.

And yes, it was successful – initial support for Oracle is done!

Oracle driver requirements

You”ll catch the problems with libdbi and Oracle in older blog posts. The new driver proposed by myself was ocilib, developed by Vincent Rogier. Currently it’s kind of a break up, so you need to have the libdbi installed and then install ocilib as an add-on (and Oracle libs and includes i.e. the Oracle Instant Client). As far as I know ocilib is not in the repositories right now so get the latest version and compile them yourself (documentation is really good!).

Modifying Configure for Oracle

If you enable IDOUtils during configure you now have the opportunity to use the flag –enable-oracle – if you didn’t install ocilib to default path /usr/local/ [lib/include] you can use

--with-ocilib-lib=/path/to/ocilib/lib
--with-ocilib-inc=/path/to/ocilib/include

to point configure to ocilib. It will be linked at runtime so you do not need to tell configure where $ORACLE_HOME and $LD_LIBRARY_PATH relays. Configure will output the following

  • export LD_LIBRARY_PATH in ido2db Initscript where ocilib resides (OCI_IMPORT_RUNTIME)
  • enable #define USE_ORACLE and ocilib.h for the compiler
  • create ido2db.cfg-sample with Oracle support

After that you can perform a normal install.

Whencompiling the code  it heavily depends on #define USE_ORACLE – if you plan to change back to another RDBM using libdbi you’ll have to issue
# make distclean
# make clean
# ./configure --enable-idoutils

Oracle Database Setup

In module/idoutils/db/ you will find oracle.sql and oracle-drop.sql. The first one creates the table definitions, a time conversion function and all the triggers and sequences needed for commonly used insert ids. oracle-drop.sql is just for testing purposes and cleans the database scheme.
Make sure you setup the Oracle DB with an appropriate scheme with username/password. Then copy oracle.sql to your $ORACLE_HOME at the db server and import it e.g. by using sqlplus
# su - oracle
$ sqlplus dbuser/dbpass
SQL> @oracle.sql

Then edit your ido2db.cfg for using Oracle. Please note that Oracle ignores the db_host, instead point db_name to //DBSERVER/DBNAME

db_servertype=oracle
db_port=1521
db_user=icinga
db_pass=icinga

That should do the trick. If you are experiencing problems turn the debug_level=-1 and debug_verbosity=2 and make sure the max_debug_file_size is set to at least 100 MB – the improved debug output will put a lot of output into that file.

Changes to the code

The biggest part has been done already getting Postgres to work – rewrite the INSERT OR UPDATE queries and extract the unique constraints for UPDATE conditions. Those queries have been adapted to use the MERGE trick. Some queries tried to issue an UPDATE where the unique constraint contained a value to be updated too. That failed heavily but introduces a really nice feature of ocilib.

By using OCI_Initialize it is possible to register an error handler function. This function simply gets the last OCI error and writes that to syslog and debug output. So it is really easy to find out why queries will fail and the nice thing is – the function doesn’t need to be called everywhere, just register it to ocilib.

Another heavy task was getting the insert id – MySQL supports last_insert_id but Postgres and Oracle don’t. In Postgres it’s rather easy defining the PK as SERIAL and getting the sequence id in order to get the last insert id. For Oracle, there are several ON INSERT TRIGGERs defined in oracle.sql which auto increment the id (primary key). Given that a specified function reads that values from the opened session.

Simply said, you do the following for an Oracle DB query in IDOUtils

  • OCI_Initialize(ido2db_ocilib_err_handler, NULL, OCI_ENV_DEFAULT)
  • oci_connection = OCI_ConnectionCreate(dbname,username, password, OCI_SESSION_DEFAULT);
  • oci_statement = OCI_StatementCreate(oci_connection);
  • OCI_ExecuteStmt(oci_statement, MT(“SELECT * FROM ….”));
  • OCI_Commit(oci_connection);
  • oci_resultset = OCI_GetResultset(oci_statement);
  • instance_id = OCI_GetUnsignedInt(idi->dbinfo.oci_resultset, 1);
  • OCI_ConnectionFree(oci_connection);
  • OCI_Cleanup();

There were some other minor and major changes to the code…

  • changed NOW() to SYSDATE
  • modify table serviceescalation_contactgroups to serviceescalationcontactgroups (30 chars max in Oracle)
  • primary key only is id anstead of [tablename]_id (30 chars max in Oracle)
  • dropped table_prefix – ido2db.cfg setting will be ignored
  • long_output uses CLOB (Character Large Object) since varchar2 supports 4000 bytes at maximum

I’ve also added a runtime version check for ocilib – if the library contains errors and does not export symbols correctly ido2db will quit correctly.

Conclusion

This is the initial version of Oracle support for Icinga IDOUtils. It was a bunch of work but there are many things to follow:

  • rewrite heavily used queries (host/service/check/status, timedevents) to prepared statements and parameter bindings
  • improve housekeeping DELETE queries with partitioned COMMITs
  • improve getting the insert ids
  • do not depend on libdbi if –enable-oracle is used

Oracle support for IDOUtils will be in Icinga 1.0 RC – watch out for the upcoming release and have fun testing! Please report any bugs or feature requests to the mailinglists and/or our dev tracker!

Many thanks to David Schmidt for implementing the first version of NDOUtils Oracle, many ideas have been improved within here. And also many many many thanks to Vincent Rogier for implementing such a great Oracle driver within the project ocilib. It is a pleasure coding based on ocilib, reading the documentation meanwhile and getting instant support for free! :-)

Since this is the third RDBM to be maintained by only 2 Core team members, please contact us if you like to participate and/or help us improving more RDBM support! :)

  • Share/Bookmark

Start Working

We just started the day with a great breakfast. Now everybody is set up, connected to the network and we are starting with a git workshop for everybody:

The agenda for today has a couple of task, e.g.:

  • multi language documentation support
  • quality review of our new web interface
  • deployment and installation strategy for api and web interface
  • further roadmap after the alpha release

Our wishes go to Michael Friedrich: He is ill and was not able to come. Get well soon.

  • Share/Bookmark

*knock knock* – Who’s there? Come in!

One point Icinga stands for is the wish to be more open. And we will release the CORE git earlier than we planned to.

Icinga is split up to three sub-projects, the core, the web and the api and now we opened one of the three doors for public review – the core door.

See it on:

Web: https://git.icinga.org

Git: git clone git://git.icinga.org/icinga-core.git

What has already been done?

We began our fork on the latest Nagios 3.1.0 code, changed the default values for the check_for_updates() stuff to ‘disabled’, included the IDOUtils (NDOUtils) to the tree but made them optional during the compile/installation progress.

The IDOUtils Code was changed to use libdbi (http://libdbi.sourceforge.net) as a C API database abstraction layer. So we should be more database independent. The big goal on this: “If you get libdbi and your favourite db driver to work, ido2db should work also.”

Tests against a MySQL database were successfull so far, but I guess we can do more on it.

If you would try it, you have to enable it during the configure part with the “–enable-idoutils” switch.

You can review the latest tracking items on: https://dev.icinga.org/projects/show/icinga-core.

I hope that we are able to open the tracker to public as soon as possible. Until then we will parse the icinga-devel list for issues and bugs and transfer them to the tracker manually.

Happy testing.

  • Share/Bookmark