Simplifying IT, Empowering Businesses

BigFix is great for endpoint management and has more than 100 million endpoints worldwide. If your organization has a large infrastructure and needs tools to make device management more efficient for both money and time, then BigFix is an excellent recommendation for you. It also allows you to check if the package has been installed based on the logic of power of relevance or not.

This blog will deal with the implementation of Datadog with BigFix and will allow you to automate your deployment processes to ensure maximum efficiency in your organization.

How to Implement Datadog through BigFix

Datadog is a data observability service that works for large cloud-scale applications and provides developers with monitoring of the servers, databases, tools, and types of IT services via a SAAS-based data platform.

The implementation discussed in this blog may seem a little complex since we already have a few servers where Datadog and YAML configurations are present. This was done so that we don’t apply them via BigFix on these servers. Moreover, we had another set of servers at DEV IT that needed to be excluded from the implantation plan.

The implantation was decided to be carried out in 3 parts as mentioned below:

1. Install Datadog Agent on all servers where it’s not present
2. Install YAML configuration file in a manner that it only gets installed on the servers where it isn’t present before
3. Create an automation plan for all such servers that might come up in future

Agent Installation

For agent installation, we had to create three installation fixlets (Windows, Linux, Ubuntu). The relevance for these was set so that it excludes all those servers that are a part of a group that the client did not want to have Datadog in. We also had to exclude servers having agents pre-installed. So, what could have been a tedious task if done manually was just a matter of a few relevant expressions through BigFix.

• An automatic group was created that could pool in all the servers from the groups that were not to be implemented with Datadog. The benefit of creating an automatic group was that every time a new server comes up in BigFix, which is of that group, it automatically gets added up to this automatic group. Also, we can add up more clauses for exclusions as and when requested by the client. In our fixlet, the relevance clause was added to exclude all the servers that were a part of this group.
• To tackle the servers which had Datadog Agent pre-installed, we created relevance expressions that could check for the presence of the Datadog agent service. Here we had another complexity wherein we were supposed to install YAML configs on all these servers if it’s not present. This was covered in the second part of the implantation.
• Once the relevance was in place, only those servers that had these relevance clauses as true were targeted, thereby reducing all our manual efforts.

YAML Configuration Deployment

For YAML deployment, the plan was supposed to be made so that only those servers are included that do not have the YAML pre-installed. These criteria included all the servers irrespective of the fact whether the Datadog agent was pre-installed or not. But we had an issue here that the YAML file was supposed to be updated after every 2-3 months, and we had to keep a counter on servers about what version of the file they presently had. Also, we had to create a method to filter out servers where YAML was already present. This was done by the methods mentioned below.

• We first created a custom property that checks for a specific OS location and returns Yes if it had a specific YAML config file present in that location.
• This property was then used in the fixlet to filter out the servers which had YAML pre-installed
• On all the servers coming in our scope now, we deployed a file that recorded the YAML file version that was successfully installed on that server. This version was then read on the console with the help of Analysis that made the reporting a lot easier. This also helped us trace failure cases much more easily, which would have been tedious if done manually.
• Once the fixlet is ready, it can be updated whenever there is a new configuration requested to be pushed by the client, and we just need to update the text file having the version stored in it.

Automating further deployment

Once the agent deployment and YAML config push were completed on all the servers, we created a method that could automatically install the agent and the config files to the new servers. For this, we created a baseline that had all these fixlets installed. We then created a policy action that would push the baselines based on the server’s OS. This way, all the new servers were added under Datadog monitoring as per the client’s request.

Conclusion

By following this blog, you will be able to create your own implementation plan for deploying your software via BigFix. It will smooth your processes in the future and save you lots of software development time. If you have any doubts about the topic, please feel free to get in touch with us in the comments, and we will get back to you.