Re: [icinga-users] configuration synchronized but not read

[Francesco Savignago]

Tried accessing https://localhost:5665/v1/objects/services

* On the master: services are returned

* On the client: services are not returned
even if they have just been downloaded in client's
/var/lib/icinga2/api/zones/...

2016-01-11 13:30 GMT+01:00 Michael Friedrich :

>
> > On 07 Jan 2016, at 16:08, Francesco Savignago <
> francesco.savign...@develon.com> wrote:
> >
> > Hi guys.
> > I have a client setup that should receive configuration from master.
> > Client of course has "accept_config = true".
> >
> > Proper configuration seems to be synced by reading logged activity.
> Infact I can find configuration files in
> > /var/lib/icinga2/api/zones/my-satellite/_etc/my-host.conf
> > and
> > /var/lib/icinga2/api/zones/global-templates/_etc/satellite.conf
> >
> > I'm sure that these files are fresh because i delete them before
> starting icinga2.
> > Synced files under /var/... are nonempty and cointains host and services
> definitions. However these objects seems not to be read since
> >  icinga2 object list --type service
> > and
> >  icinga2 object list --type host
> > give empty results.
> >
> > I have no idea why. I can find log lines such as
> >   information/ApiListener: Updating configuration file:
> /var/lib/icinga2/api/zones/my-satellite//_etc/my-host.conf
> > but no lines such as
> > "Received 'config::Update' message from 'Master'"
> > That I found googling about.
>
> Are these objects accessible via REST API?
>
> Kind regards,
> Michael
>
> >
> > Any idea will be appreciated.
> > TIA
> > ___
> > icinga-users mailing list
> > icinga-users@lists.icinga.org
> > https://lists.icinga.org/mailman/listinfo/icinga-users
>
>
> --
> Michael Friedrich, DI (FH)
> Senior Developer
>
> NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461
> http://www.netways.de | michael.friedr...@netways.de
>
> ** OSDC 2016 - April - netways.de/osdc **
> ** OSBConf 2016 - September - osbconf.org **
> ___
> icinga-users mailing list
> icinga-users@lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users
>
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] Custom interval service checks not showing properly in web2

[Horatiu N]

I have configured check_interval for 10m in templates.conf but in web2 i
see it rechecking each 60 seconds.
Here's my service object :

> Object '!ssh' of type 'Service':
[...]
>   * check_interval = 600
> % = modified in '/etc/icinga2/conf.d/templates.conf', lines 28:3-28:22
>   * check_period = ""
>   * command_endpoint = ""
>   * display_name = "ssh"
>   * enable_active_checks = true
>   * enable_event_handler = true
>   * enable_flapping = true
> % = modified in '/etc/icinga2/conf.d/templates.conf', lines 30:3-30:23
>   * enable_notifications = true
>   * enable_passive_checks = true
>   * enable_perfdata = true
>   * event_command = ""
>   * flapping_threshold = 30
>   * groups = [ ]
>   * host_name = ""
[...]
>   * max_check_attempts = 5
[...]
>   * retry_interval = 60
[...]

So it properly assigns the values from the template.

> template Service "generic-service" {
>   max_check_attempts = 5
>   check_interval = 10m
>   retry_interval = 60s
>   enable_flapping = "1"
> }

The problem is, in web2 when I check the service I see
Last check : 0m 10s ago
Next check : in 0m 50s

also, in the debug log if i grep by !ssh i see recurring messages
each 60 seconds.

As i understand check_interval defines the distance in time between
checks and retry_interval is applied after a 1st failure. in my case
once 5 failures are detected successively a notification would be sent.
So in my case i check once every 10 minutes and if the service is down i
would get notified in 15 minutes (5x60=300).

Did i get it all wrong ? why does it keep checking every 60 seconds ?

... I'm lost.




smime.p7s
Description: S/MIME Cryptographic Signature
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] We miss Availability Reports

[Davide Demuru]

Hi Guys,


Feature #4071: Availability report

Feature #4071: Availability report - Icinga Web 2 - Open Source 
Monitoring
dev.icinga.org
Redmine


Is there any chance to see this feature available soon?


Thanks in advance!

Regards
Davide



Davide Demuru

IT System Analyst

Monitoring &  Ticketing Administrator

BUONGIORNO S.p.a. - NTT DOCOMO Group



___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] how do i get rid of service notifications when host state is down/recovered

[Horatiu N]

In a test environment i have icinga2 monitoring a vm with ssh enabled.
Whenever i suspend the vm icinga2 sends the following emails:

PROBLEM - VM - ssh is CRITICAL
PROBLEM - VM is UP (confusing, but the reason is Additional Info: PING
WARNING - Packet loss = 96%, RTA = 0.34 ms)
PROBLEM - VM - ping4 is CRITICAL
PROBLEM - VM is DOWN

and when i resume the vm :

RECOVERY - centos7 is UP
RECOVERY - centos7 - ping4 is OK

I want to get rid of the ping4 recovery notification - it's useless.

Ideally I want to be notified of the VM being DOWN. and then UP.
And receive ssh notifications only when the VM is up and i intentionally
turn off ssh.

I thought service dependencies on their own host were automatic. they
aren't ?



smime.p7s
Description: S/MIME Cryptographic Signature
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

[icinga-users] _feature request?_ enabling only one notification when most systems go down

[Horatiu N]

When something big happens (no false positive) and connectivity is lost
to most monitored systems notifications flood the inbox.
Can this be somehow prevented by sending only one notification ie based
on a threshold so that when 60% or more is down only one message is sent
"Almost all systems down" for example.



smime.p7s
Description: S/MIME Cryptographic Signature
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] Refactoring Icinga2 configuration language?

[Michael Friedrich]

Hi,

> On 11 Jan 2016, at 16:47, Paul C  wrote:
>
> Is there any discussion on refactoring the scripting language within Icinga2? 
>  After trying to train a few people and migrate some Icinga1 configs I'm 
> having mixed feelings about how it works now.  Sorry in advanced if these 
> things sound misinformed since I'm no expert on Icinga2.  Nonetheless, these 
> things are fresh on my mind and was hoping to get some feedback.

No worries. It is always hard to change, coming from the “old” world with some 
“simple” key value pairs on objects to a more modern somewhat dynamic 
configuration language. I guess it is easier to start “fresh” rather than 
migrating from different strategies in the past.

After all, Icinga 2 is 1,5 years old with its first stable release on 16.6.2014 
- and we changed quite a few configuration methods and strategies before 
releasing 2.0 … the first Icinga 2 commits happened somewhere in March 2012, 
and you might see that change from older blog posts targeting the pre-releases 
0.0.x. What we have now is something more mature and stable than it was before.

>
> 1) If the default installation did not use any scripting functions it would 
> make it easier to learn out of the box.  The scripting support could then be 
> its own section in the docs instead of spread out.
> 2)  It would be a more lean and stable core if the scripting support was an 
> optional package (or at least it could be turned off).

Icinga 2 is a configuration DSL on its own, there is no “scripting support” in 
it. So you cannot just “turn it off”.


> 3) Feature creap... i keep seeing new features like "if" statements to 
> address common scenarios which forces me to revisit the docs after every 
> upgrade.

That’s fairly normal when development of new features requires configuration 
changes or even new ideas generate new DSL keywords. It is nothing you’d 
generally want for 2.0+ making it feature-complete, but the reality in modern 
software development shows and proves different.

Revisiting the documentation on upgrade is a good practice anyways. So you’ll 
learn about new features instead of trying to adopt examples found on the net, 
or never reading about it and not having a chance to evolve. You might feel bad 
about it, but hey, after looking into cool new stuff you’re normally excited to 
learn about it. And if not, just ignore it.

All-in-all these language additions were implemented with upgrade safety in 
mind. If you do not need for example conditional statements, do not use them. 
If you prefer to solve a problem more elegantly, come back to a new version and 
check its new features. Or certainly ask on the community channels how others 
do solve it. Neither configuration nor programming scripts are 100% perfect and 
can always be improved in many ways.

Unless the Changelog explicitly adds a breaking change your existing 
configuration is always safe to use on upgrade. No-one will accept software 
changing its configuration language on every major release, or changing the way 
(openldap 2.4 is my personal “headbanger”).



> 4) Pre-load scripts via a hook.  If it is not already possible, it would be 
> nice to tell Icinga2 to run some pre-load scripts that are too complicated to 
> be converted to Icinga2 native scripting...  A simple version could have 
> Icinga pass its config via json to the external script and use the resulting 
> json as the configuration.

That would require read/write/etc language additions allowing you to load an 
external file and decode the json object. Not sure if that’s wanted or needed 
currently. Users tend to solve such “conversion” issues with their own tool 
stack being familiar with it. Though if you provide a detailed feature request 
on dev.icinga.org we can sure think about it and discuss implementation 
scenarios.


> 5) More modular runtime scripting.  If the icinga scripting language was (if 
> not already) a module with a standard interface, that would allow people to 
> create adapters for the API allowing scripting in JavaScript, Python, etc…

Not sure if I can follow here - can you give an example?

> 6) Future options... if there is a JSON or javascript module,  that would 
> allow Icinga2 to easily change from a proprietary config format to JSON, YAML 
> or whatever.

Icinga 2 should (and imho must) only have *one* configuration DSL, and not 
multiple different ones. There’s only one way to do it right. “proprietary” is 
also not the correct term imho - the configuration language is documented in 
all of its details. I’m fairly certain users don’t want to learn yet another 
configuration language different to the one already existing. Apart from that I 
highly doubt that JSON or YAML provide the language features Icinga 2 already 
has implemented - they define a format, but don’t really compare to Icinga 2’s 
DSL.


>
> I know some of these ideas at first glance may not seem feasible given 
> sattelites and misc node synchronization but if the int

[icinga-users] systemd unit file issue

[Lee Clemens]

Hello,

I noticed on a server without mariadb.service present (or presumably another 
service/unit further requiring network), that icinga2.service would attempt to 
start before network (race) and would usually fail with critical/ApiListener: 
Cannot bind TCP socket for host.

Adding 'network.target' to the [Unit] After argument in the unit file resolved 
the race condition.

I'm not sure this is the right place to report this issue (Using 
icinga2-common-2.4.1-1.el7.centos.x86_64 from 
http://packages.icinga.org/epel/$releasever/release/).

-Lee Clemens
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [icinga-users] Refactoring Icinga2 configuration language?

[Paul C]

Thanks for the feedback.  I will try to put together a feature request for
the pre-load script hook since that would address our key needs.  We feed
service definition data from many different sources such as Postman json
and WSDL files, databases, csv files, etc...  One problem is we constantly
generate new service definitions and we want the current configuration
passed to us so our configuration generating scripts can revise contact
groups, determin if some other system already imported a service of the
same name, etc...  We already do this but it would be nice if there was a
standard way to do it.

On Tue, Jan 12, 2016 at 10:54 AM, Michael Friedrich <
michael.friedr...@netways.de> wrote:

> Hi,
>
> > On 11 Jan 2016, at 16:47, Paul C  wrote:
> >
> > Is there any discussion on refactoring the scripting language within
> Icinga2?  After trying to train a few people and migrate some Icinga1
> configs I'm having mixed feelings about how it works now.  Sorry in
> advanced if these things sound misinformed since I'm no expert on Icinga2.
> Nonetheless, these things are fresh on my mind and was hoping to get some
> feedback.
>
> No worries. It is always hard to change, coming from the “old” world with
> some “simple” key value pairs on objects to a more modern somewhat dynamic
> configuration language. I guess it is easier to start “fresh” rather than
> migrating from different strategies in the past.
>
> After all, Icinga 2 is 1,5 years old with its first stable release on
> 16.6.2014 - and we changed quite a few configuration methods and strategies
> before releasing 2.0 … the first Icinga 2 commits happened somewhere in
> March 2012, and you might see that change from older blog posts targeting
> the pre-releases 0.0.x. What we have now is something more mature and
> stable than it was before.
>
> >
> > 1) If the default installation did not use any scripting functions it
> would make it easier to learn out of the box.  The scripting support could
> then be its own section in the docs instead of spread out.
> > 2)  It would be a more lean and stable core if the scripting support was
> an optional package (or at least it could be turned off).
>
> Icinga 2 is a configuration DSL on its own, there is no “scripting
> support” in it. So you cannot just “turn it off”.
>
>
> > 3) Feature creap... i keep seeing new features like "if" statements to
> address common scenarios which forces me to revisit the docs after every
> upgrade.
>
> That’s fairly normal when development of new features requires
> configuration changes or even new ideas generate new DSL keywords. It is
> nothing you’d generally want for 2.0+ making it feature-complete, but the
> reality in modern software development shows and proves different.
>
> Revisiting the documentation on upgrade is a good practice anyways. So
> you’ll learn about new features instead of trying to adopt examples found
> on the net, or never reading about it and not having a chance to evolve.
> You might feel bad about it, but hey, after looking into cool new stuff
> you’re normally excited to learn about it. And if not, just ignore it.
>
> All-in-all these language additions were implemented with upgrade safety
> in mind. If you do not need for example conditional statements, do not use
> them. If you prefer to solve a problem more elegantly, come back to a new
> version and check its new features. Or certainly ask on the community
> channels how others do solve it. Neither configuration nor programming
> scripts are 100% perfect and can always be improved in many ways.
>
> Unless the Changelog explicitly adds a breaking change your existing
> configuration is always safe to use on upgrade. No-one will accept software
> changing its configuration language on every major release, or changing the
> way (openldap 2.4 is my personal “headbanger”).
>
>
>
> > 4) Pre-load scripts via a hook.  If it is not already possible, it would
> be nice to tell Icinga2 to run some pre-load scripts that are too
> complicated to be converted to Icinga2 native scripting...  A simple
> version could have Icinga pass its config via json to the external script
> and use the resulting json as the configuration.
>
> That would require read/write/etc language additions allowing you to load
> an external file and decode the json object. Not sure if that’s wanted or
> needed currently. Users tend to solve such “conversion” issues with their
> own tool stack being familiar with it. Though if you provide a detailed
> feature request on dev.icinga.org we can sure think about it and discuss
> implementation scenarios.
>
>
> > 5) More modular runtime scripting.  If the icinga scripting language was
> (if not already) a module with a standard interface, that would allow
> people to create adapters for the API allowing scripting in JavaScript,
> Python, etc…
>
> Not sure if I can follow here - can you give an example?
>
> > 6) Future options... if there is a JSON or javascript module,  that
> would allow Ici