EXISTING CUSTOMERS COMING FROM VERSION < 0.7.1.0 As of version 0.7.1.0 Overwatch will begin sunsetting the “legacy” deployment (Notebook | JAR) method and Legacy Configuration. Please review the benefits of using the new deployment method and plan to switch to this new deployment method by end of Q3 2023. New customers may disregard this notice.
Overwatch is a pipeline that executes to aggregate and normalize all of the logs from all the supported sources and make them easy to interrogate for insights. The steps to deploying Overwatch are pretty simple but there are some specific details that may pertain to your deployment. Below are the top level steps that this section will walk you through the process.
Select your cloud to find the details for cloud configuration here. (AWS | Azure)
Reference Security Considerations page to help you build and apply a security model commensurate with your needs.
Reference the configuration page to clarify the configuration details and help you get started.
For legacy deployment methods please reference the Legacy Configuration Page
Decide whether you’d like to execute Overwatch as a JAR or a NOTEBOOK and schedule a job to periodically execute the job.
It’s recommended to run Overwatch as a JAR as it unifies the deployment and doesn’t depend on another asset (the notebook) to secure and ensure no one edits, moves, or deletes it.
Now that you’re live it’s important to optimize everything and ensure the data is safe in case something unexpected happens – see Productionizing
Now you’re ready to onboard consumers across your workspaces. Details about how to do that can be found in the Sharing Overwatch page.
As of 0.7.1.0 Overwatch is able to monitor remote workspaces but having one and only one global deployment often doesn’t meet customer needs and there are some requirements for a deployment to monitor remote workspaces. More details are available on the Security Considerations and Validations pages. The most important things to consider are:
If some of your workspaces do not meet these requirements; that’s ok, a local deployment with a simpler config will need to be created for those outliers. It’s completely fine to have a primary deployment that manages 20 workspaces and a few workspaces that have to have their own Overwatch Job. The data from each deployment can be dropped into the same or multiple targets, this is all part of the configuration.
Assume you have 23 workspaces, 20 of which meet the criteria discussed above and 3 that need to be locally configured. All 23 workspaces an output their data into the same database (or multiple) but this would require that Overwatch run on 4 workspaces, 1 to manage the 20 and 1 on each of the 3 with special requirements.
Production can hold the data for all 23 workspaces even if some of the workspaces are deemed “non-prod”. This is ideal to allow an analyst to identify efficiency gains and metrics globally from a single location.
A non-prod Overwatch deployment is also recommended so that when new versions come out and/or schema upgrades come out your team can review and test the upgrade and update any dependent dashboards before you upgrade all 23 workspaces.
A non-prod Overwatch deployment typically consists of a subset of the 23 workspaces (usually 3-5 workspaces). This deployment will always be upgraded and validated before the global production deployment. This pattern enables Change Management best practices. Non-Prod and Prod can even be deployed on the same workspace just with two different configurations such that the non-prod has its own database names and storage locations.