larssb / healops Goto Github PK

Should have done this a long time a go.

On some systems the delimiter is '.' and on others it is ','. Relative to the culture of the OS. Find a way to determine the OS and incorporate it in HealOps where needed.

There is a couple of areas on this.

• In order to support querying HealOps for a health status on a node running HealOps. So that a HealOps health dashboard can be setup. Would be a nice tool for troubleshooting HealOps.
• Make it possible to have the Log4Net logging framework used by HealOps, configured so that logs could be potentially exported/sent to a log endpoint like logstash, papertrail and the like.

Have a Fallback value on: "UpdateMode". The Default value should be >> HealOpsPackage. In case that an update fails and corrupts the HealOps config file.

To clarify and so forth.

Infer the MSSQL user the same way that the MSSQL instance is inferred.

E.g. you have options in the cloud such as > https://www.youtube.com/watch?v=Gd6vV3Qn9KA ... Azure Automation, OMS and RunBooks. Then why HealOps?:

• It's free, in a direct get out your wallet type of way.
• Can be customized. In the extreme > just do a fork.'
• No lock-in to Azure, AWS or another product.
• ....

If it is, act accordingly in the code.

In order to avoid loosing any reports, if/when the reporting backend is down or, in the case that som issue results in HealOps being unable to submit a report to the backend.

Suggestion/s:

• Save the report to a JSON or YAML file. In a "cache" folder.

• Point to the license URI
• ProjectURI
• Give it some tags.

To heighten security. Basically to secure secrets use HashiCorp Vault. Already have a integration for Vault in store. Use that (FranzJaeger).

• Implement Vault
• Document it

The idea is:
-> Have one update job on a node running HealOps. This job will run everything related to updating HealOps and HealOpsPackages.
-> Or have a job that updates HealOps and the jobs that executes a *.Tests.ps1 file in a HealOpsPackage will look for updates to the HealOpsPackage.

Benefits:

• A potential simpler way of updating. And the scenarios involved therein.
• Seperation of concerns. Normally a good road to follow when implementing/developing software.
  --> One UpdateMode
  --> One ReportMode
  --> One StatsMode

Potential issues:

• Invoke-HealOps could already be running. So issues with locks & so forth. Think about this really is a issue or not. Only an issue if the one for all Update job way is chosen.

Document how to best contribute to the project. A list of potential requirements. Code of conduct and so forth.

The JobType parameter does not need to be mandatory anymore. As info is set in the HealOpsPackage config file.

Read the guidelines on Planet PowerShell.

It should be possible to use GitHub to host the page. If not there is plenty of other options. No matter what I need a good website with documentation.

Use a JSON schema

Would be great to have/do in order to ensure conformance to what is needed by HealOps and a HealOpsPackage. And making it easier for a developer of a HealOpsPackage to know that they are doing things as they are supposed to.

(or if YML is chosen a schema fitting that format).

Consider supporting YML for the config files.
The foremost reason is to get the option of commenting on the lines in the configuration file. Besides, it heightens the readability of the configuration file.

Downsides:

• Adds an extra pre-requisite to HealOps. powershell-yaml
• And code work to incorporate it.

• Documet how-to.
• Set it up.

It should be not be required to manually login to 'x' server in order to install HealOps. Instead support different deployment methodologies.

Consider what to support from the following list.

• Ansible
• VMWare tools
• PSRemoting

It would be "nice" of us to validate the metric format in the Write-MetricToOpenTSDB function.

The format:

• Should conform to "sss.sss.sss.sss.sss".

The way Invoke-WebRequest, which is used for downloading modules from the package management backend, is slow. Look into fixing this.

• Find the proper way to do it. As we can not report back to 'x' time series database.
• Is e-mail good enough, it is not a fail-safe way (SMTP is not fail-safe)
• Slack? Would be good.
• A direct implementation to 'x' incident management system like OpsGenie. Through a WebHook or whatever.

When the Environment differs and a generic HealOps package is used. We need to find a way to support this situation without the end-user having to manually edit the HealOps package configuration file.

This is not the case currently. Unnecessarily update mode code is invoked. Not good - but bad!

Fix this.

Attaching pictures need to work. Troubleshoot and fix the issue.

Will be of great help when troubleshooting and for general documentation.

We need to have an easy way to Uninstall HealOps from nodes whereon it has been installed.

It is basically about turning the Install-HealOps code upside down ;-)

If not used, errors will be thrown when running tests as Log4Net has not been initialized. Because logging is not used when executing the tests.
By using the -Debug common parameter we can do a conditional on that and avoid exceptions related to the above.

• Document how.
• Set it up.

Implement a "Job Engine" on Linux and MacOS. Likely via Cron.