Spinnaker Webhook Configuration

A listening webhook can be configured in Insights where Spinnaker will forward payloads with event details whenever any event(viz. pipeline execution, cluster deletion etc.) occurs through the Spinnaker UI. The echo-rest module in spinnaker is used to set downstream listeners to keep track of Spinnaker events. It will forward any event received from orca, igor or echo to the webhooks registered.

Here we will use our InSights webhook functionality to generate a listening webhook and integrate the same with Spinnaker.

Prerequisites:

Steps to configure:

Login to InSIghts and click on the Configuration -> Webhook Configuration option.

2. Click on the “+” icon highlighted in the webhook configuration screen to add a new webhook:

3. Provide all necessary details such as the name of the Webhook, what is the tool for which it will be used, the label with which data will be forwarded to Neo4j etc. All fields marked with asterisk(*) are mandatory fields. (Refer here for more details)

4. The Response Template defines which fields are to be consumed by InSights. Values inside this field should be comma separated. Below is an example response template for Spinnaker events:

details.type=eventType,
details.created=creationTime,
details.application=application,
content.executionId=executionId,
content.execution.name=name,
content.execution.status=status,
content.execution.startTime=startTime,
content.execution.endTime=endTime,
content.execution.description=description,
content.context.serverGroupName=podName,
content.execution.trigger.user=username,
content.taskName=taskName,
content.context.canaryConfigId=canaryConfigId,
content.context.canaryScore=canaryScore,
content.context.scoreThresholds.pass=passScore,
content.context.scoreThresholds.marginal=marginalScore,
content.context.canaryPipelineStatus=canaryStatus,
content.context.scopes.default.controlScope.scope=base,
content.context.scopes.default.experimentScope.scope=canary

The left hand side defines the property coming from Spinnaker payload and the right hand side defines the name with which it will be stored in Neo4j (You can provide your own names here). The dot (.) is used to define nested properties.

5. Once all details are filled, click on the save icon highlighted below:

6. This will take you back to the main Webhook configuration page. Select your webhook and Click on the link icon to copy your webhook. Keep it handy, this will be used later for Spinnaker.

Login to the halyard instance from where you have deployed Spinnaker. Navigate to the following path:
~/.hal/default/profiles
Create a new file here called: echo-local.yml
Write the content below into your newly created echo-local.yml file:

rest: enabled: true endpoints: - wrap: false url: <Insights_Webhook_Configured_In_Step_1>
Save the file and run the following command:
hal deploy apply

This will redeploy Spinnaker with your changes, and all event payloads will be forwarded to the InSights webhook.

You can configure multiple webhooks, where Spinnaker will forward the payloads to all of them simultaneously. In such scenarios, the echo-local.yml file will look like this:

rest:
enabled: true
endpoints:
-
wrap: false
url: <webhook1>
-
wrap: false
url: <webhook2>

Reference: click here

Default Spinnaker Dashboards

Upon configuring the webhook, the data flowing into InSights can be represented into meaningful Key Performance Indicators, which can provide a holistic view of the activities inside Spinnaker. We have used Grafana to depict a few such KPIs as graphical panels that might be useful for business analysis. Below are the KPI’s available:

Total number of Deployments:

Signifies the total number of deployments done via Spinnaker with (pass/fail distribution) as a doughnut chart.

2. Monthly Deployments over time:

Number of deployments happening each month, along with passed/failed deployment distribution.

3. Application Details:

Table containing application names, pipelines executed that are part of the said applications, number of times the pipelines are executed and the distinct outcomes of such executions.

4. Pipeline Execution Details:

Tabular panel containing the details of each pipeline execution (eg- name, status, Date and time of execution etc.)

5. Average Deployment Time:

Time taken to complete a deployment (pipeline execution) along with the overall average time (in minutes).

6. Canary Analysis Panels:

Top 10 Canary Pipelines:

Top 10 pipelines (according to their time of execution) and their execution status.

Canary Overview:

Details of canary pipeline executions (eg – execution status, canary scrore, score boundaries etc.)