Zabbix 5 - Can an item be monitored only at certain circumstance? - triggers

I am using Zabbix 5. As long as I know, there are item dependencies and trigger dependencies.
Other than that, I am curious if I can set a condition for an item to be monitored only at that condition.
For example, if one firewall device gives 0 ping back, then I want to start monitoring (or sending pings) to a L2 device which is above that firewall device. So, my L2 device will be monitored not all the time but only when I get a trigger. Is there such functionality available in Zabbix?

Not natively. Actually I don't see the usefulness for a "light dependancy" like that.
However, a possible workaround:
create the L2 device item (ping, tcp port etc..) and disable it.
create a custom action for FW unreachability to launch a custom script, for both problem creation and problem resolution
the script should do an api call to enable/disable the L2 device item

Related

SCOM Rule for Fake Alerts

I am working on a tool to generate fake data for System Center Operations Manager for internal testing purposes. I wrote a script as part of a discovery that is able to create an instance of any class I want and make SCOM fake-discover it. Currently, I'm using a class for AD Printer. Now the next step is to somehow create alerts on behalf of the Printer. For this, I wrote a rule targeted at the AD Printer, which reads from the logs to detect when it should be fired. The logs are being written to from a PowerShell script. However, I see no results. But when I target the same rule to All Windows Computers, I see the alerts.
From what I understand the rule will run on all agents that have an instance of the target class. Since I fake-discovered the AD Printer on this agent (which also happens to be the Management Server), should the rule not run on this?
Any other suggestions on how I can achieve this are welcome as well.
PS. I probably cannot share any of my code as I am under an NDA, but I can clarify my approach further, if needed.
Yes, the Powershell script should run on the agents which have instances of the AD Printer. I recommend you to check the OperationsManager event log for script errors. The easiest way to generate (fake) alerts is to set up a simple, Event-based text log monitor: one specific word can trigger the unhealthy state (which in turn generates an alert), while another word resets the monitor to the healthy state. You can specify criteria for both events. Look at this blog post for further details.

Zero downtime deployment of Slack bot

We develop bot with BotKit and now we try to solve problem with minimal deployment downtime.
There are the server and docker container running on this server. Inside container run bot-app instance connected with RTM-server (Slack).
When I start to deploy new version (v2) of bot-app, I want to get zero downtime, users should not see "bot is offline".
Deploy script runs second docker container with a new version of bot-app. And bot-app connect to RTM-server too. In this way, there are few seconds, when both apps run, connected to RTM-server and responds to user commands (and a user will to see two answers to his command).
What optimal decision I can get if on the one hand we want to get zero downtime and on the other hand, we want to prevent the user interact with the two instances at the same time?
Decision 1:
To allow small chance the likelihood of a collision, when both instances will respond to the user command.
Decision 2:
Abandon the zero downtime deployment. In this case, deploy script first stops the first docker-container, then start another one. The app will not respond to user commands, sent between stopping current version of the app and fully starting of a new version of an app.
Decision 3:
With an interact of parallel run current and new version of app or mutexes. General schematic:
1) Current version of app is running
2) Deploy script starts new version of app
3) I time when a new version of app almost run and ready to connect to RTM-server, it send to current version app command to close RTM-connection.
4) Current version of app closes RTM-connection
5) New version of app open RTM-connection
I think there are other good solutions.
How would you have solved this problem in your application?
(Sorry for the second reply; had another idea.)
The approach I described earlier would be pretty disruptive to your existing code, since you'd probably need to stop using botkit (or at least not use it to do the RTM API communication). An approach that may be less disruptive would be to use some sort of external way to signal that a given message is already been processed.
For example, using Redis, have the bot do the following command when a message comes in:
SET message:<message timestamp> 1 NX PX 30000
The NX option means this command will only succeed if the key doesn't already exist. So the first instance of the bot that manages to execute this will succeed, and the other instance will fail. The bot should only process the message and respond if this command succeeded.
(The PX 30000 sets a 30-second expiration so Redis doesn't get full of these keys.)
This should let you do your zero-downtime upgrades via overlapping the running bot instances without having to worry about a message being processed twice.
Note that it's still possible in this scheme for a message to be dropped altogether if a bot is shut down in a non-graceful way. (It could die just after calling the SET command but before it's actually dealt with the message.) A real queue with a two-phase "get/delete" would be better, but then you're back to my other answer. :-)
One idea I would consider is separating into two components:
A component that keeps a WebSocket connected to the Slack RTM API. This component simply reads messages from the API and puts them on to a queue. (Let's call this the "queuer.")
The actual "bot," which reads messages from the queue and responds as needed.
Depending on how your bot behaves, it can use the Web API directly or perhaps put its own messages on an outbound queue which the "queuer" can send via the RTM API.
This architecture probably solves your problem... you can now either take the bot down briefly while upgrading—responses will just be delayed until the new version is running—or you can run two versions of the bot at the same time and rely on the semantics of the queue to prevent both versions from responding to the same message.

Would pull be better than push from a set top box?

We work in the area of video streaming and we are writing some software for a set top box that queries our server for a list of channels (NBC,FOX etc) so that it can select one. Also it needs to tell the server what it is currently doing (i.e. which channel selected, is it playing or paused etc) as the user can control the STB with remote control.
Also from another UI to the server another user can change the channel that is played on the STB.
So my question is an architecture one - would it be better for the STB to poll the server every so often (say few seconds) or should the server push the changes and check the STB every few seconds. There could be 100s of set to boxes.
I was thinking about exposing a number of web services and then the STB would poll and with each poll if there is change from another user it can then react otherwise each poll would be a status update.
In addition, whatever design we come up with we should be able to expose our API to 3rd party STB manufacturers so that they work with us.

ICS VpnService pop up dialog

I am trying to write a VPN app using VpnService. I started my app based on the sample ToyVpn. It seems to work fine but I am wondering if there is a way to get rid of the pop up dialog when I click connect. I am hoping that I could just click "connect" and it would start without having to click the "I trust this application..." check box and "Ok".
Thanks.
I don't think it's possible. They seem to be very careful about this class. If you take a look at the documentation you can see it says:
Letting applications intercept packets raises huge security concerns. A VPN application can easily break the network. Besides, two of them may conflict with each other. The system takes several actions to address these issues. Here are some key points:
User action is required to create a VPN connection. [emphasis mine]
There can be only one VPN connection running at the same time. The existing interface is deactivated when a new one is created.
A system-managed notification is shown during the lifetime of a VPN connection.
A system-managed dialog gives the information of the current VPN connection. It also provides a button to disconnect.
The network is restored automatically when the file descriptor is closed. It also covers the cases when a VPN application is crashed or killed by the system.
Since it says that user action is required to create the VPN connection, I assume they mean this is something you cannot control yourself.

AFNetworking + current reachable interface

I have a UITableView showing a list downloads located on my own server. Each row has its own download button. Since some of them have a size greater than 50Mb I would like to disable their download button to save user money and experience when they are under 3G only (WWAN).
I'm already using AFNetowrking and I know that they plan to support flags for current reachable interfaces in some experimental branch on github, but I prefer to use that code only when it become stable production/ready code.
I need something like 3 kind of status:
Not Reachable
Reachable via WWAN
Reachable via WiFi
How can I accomplish my goal with just AFNetworking? Do I have to add another library?
NOTE: i'va already a lot of working code deployed into this app, most of it relies on AFNetworking so replacing this library, couldn't be an option.
Hold tight for a few more days. I'll have that pushed out by the end of the week :)
Edit: 1.0RC1 is now merged into master. Enjoy!