Automated onboarding of Database Services

[radioactive9 (Anirban)]

Hello

I am back with another question - seeking guidance.
I am trying to automate multiple single service onboarding for postgres DB

I have a Host-Template → XXX_templhost_PG
In this Host-Template I have existing Postgres Single Service Already Deployed.

Now when a New Server comes needed for Postgres Monitoring - all we manually do from director is to add the XXX_templhost_PG Host-template for the server

Now automatically the Single Services Gets assigned for that server.

Question 1: How do I automate the step? Using director-api or icinga-api (if you can point out to the document or give a hint it will be great.

Now the next problem:

Once the services are assigned all single services gets distributed. But for PG the DBs are unique.
So for that server we have to override manually in director the service and populate the dbname field.

So for all the 10 services for Postgres lets say I want to override one field for that server with the value of the dbname which I have in a script already.

Question 2: Is there a director API which can help me to automatically override a field for a single service for a single server.

I have to override
postgres_dbname
postgres_dbuser
postgres_port

Regards

Anirban

[dgoetz (Dirk Götz)]

Before answering your questions I recommend looking into Service Sets assigned by Data fields as they are more flexible to assign and easier to handle Single Service assigned to Host templates.

But it does not matter for how to solve it. For automation I would recommend using import and sync mechnism of the Director, but if there is no source and the information has to be pushed into the Director. You can use its CLI or API. Changing an object would be a set via CLI or POST/PUT via API.

Also you do not have to use the override in the director for your use case, Icinga 2’s logic is host variables override defaults of checkcommands which than can be overriden at services. So if you keep the values empty at the service and set them on the hosts it would be much easier.

To make it really nice looking I would add a datafield to the hosts like applications where I add PostgreSQL to flag my database servers, perhaps even provided from a data list. Then I would create a Service Set for the postgres checks and assign it to hosts where PostgreSQL is in the array of applications. The datafields for dbname, dbuser and port I would add to a datafield category PostgreSQL and add them as mandatory to the Host template with a filter, so they are also only shown when PostgreSQl is in the array of applications. Now a user of the webinterface can select the application PostgreSQL and will then be shown the additional fields required needed to save the host. And for automation I would only need to set 4 fields at the host.

[radioactive9 (Anirban)]

Wow. Nice suggestion. Why I din’t ask this question earlier
We actually onboard Linux automatically with Linux Monitoring by icinga using salt states first. Then later on another salt workflow decide whether this VM will be assigned to Postgres or WebApp or MQ etc and what not and install postgres /respective application and send us email that it is Postgres.
Then currently we onboard into Postgres. Now when initially the host gets onboarded we don’t know whether it is going to be postgres. So we still have the change the host values later as well

If you don’t mind can you please put some screenshot. We will have to continue with Host-Template and Single Service Deployed on the Host-Template for now. Lot of the hosts and services has been onboarded by this method. But Do I have a option to update the host vars with the dbname and dbuser details during host onboarding - and somehow pass / link that information in the single service vars? for that host. Can you please help with an example ?

Like for postgres server lets say we set a field called DBName and DBUser in the host.vars.dbname and host.vars.dbuser
Then in single service - we just mention in the field postgres_dbname=host.vars.dbname
postgres_dbuser=host.vars.dbuser
Do you think it will work?

[dgoetz (Dirk Götz)]

Sorry, I did not realize that you edited your post to add more questions after I had read the first paragraph!

Screenshots is always a bit troublesome that most of my productive examples are from customer environments where I can not easily make them, but I recreated the example locally as I perhaps can use it later again as a demo case.

This screenshot show the Datafield for my Applications, you should add some description too, but most important is for the nice workflow is the Datalist which contains my Applications but also allows to add additional values and the Data Field Category.

Nothing special for the Datalist and the Data Field Category, so next one is from adding a host. Here you can see the data field in action.

And when postgresql is added to the applications the new fields are shown (Password has visibility “hidden”)

This is done when the field is added to a host template via filter.

So back to how we can handle this for now. I think it is not so complicated and should already work if you remove the value from the service as the override will still override the empty value and then you can set it on hosts and remove the override whenever you touch a system. If you somehow use the defaults somewhere and not use override on every host, you would need to identify these hosts and the value there before removing the service defaults.

But just to make it sure, you need exactly the same fields then at the host, so it would be postgres_dbname for host and service. If you want to use different names you would need to explicitly set them like you mentioned so it would be postgres_dbname=host.vars.dbname on the service like in your example.

[radioactive9 (Anirban)]

Thank You very much @dgoetz. Believe me - I really owe you a coffee @starbucks
This is perfect solution thank you very much

[dgoetz (Dirk Götz)]

If you meet me on a conference or Icinga camp after this pandemic ended, I will gladly take it or if it is afternoon a beer instead!