Skip to content

Truncate AlertManagement::Alert fields which may be too long

Sarah Yasonik requested to merge sy-truncate-alert-fields into master

What does this MR do?

Context

GitLab can be configured to receive alert notifications from external services.

When an alert comes in, we parse the payload and save the content to an instance of AlertManagement::Alert. We limit the length of various fields (title, description etc), but if an alert comes in which exceeds these limits, we'll fail to save the instance & return an error response on the request.

However, most alerting systems are automated & this would essentially look like a dropped alert to the user. "We want to do everything possible to AVOID missing a new alert."

Changes

This MR truncates incoming content for fields which exceed the length limits on AlertManagement::Alert, replacing the last three characters with ... to indicate the truncation to the user.

  • title, description, service, monitoring_tool are strings & can be truncated directly.
  • hosts is an array of strings which has a length limit based on joining the strings together. As this is an edge case, I've opted to truncate in a fairly simple way which always returns an array of strings one level deep (not nested).

The corresponding documentation is in line with this change, as now the only true hard limit is the payload size. https://docs.gitlab.com/ee/operations/incident_management/alert_integrations.html#customizing-the-payload

Testing & Screenshots

A test alert can be triggered by going to project > Settings > Operations > Alerts & triggering a test alert for the HTTP Endpoint option.

Test payload:

{
  "title": "This is a really bad issue which should be cut off partway through because titles should be short and this title is starting to get really long - it's unruly really someone should really get some sort of limit on this",
  "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec in scelerisque purus, eu vestibulum leo. Quisque et sapien urna. Sed vestibulum tortor ut molestie posuere. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse ante turpis, tempus in ligula in, ullamcorper lobortis nisi. Duis in suscipit ipsum, vitae pulvinar urna. Nulla eget varius tellus, sed aliquet nisi. Pellentesque in convallis quam. Praesent eu lorem euismod, cursus nulla ut, varius lorem. Sed pharetra libero sit amet sem hendrerit suscipit. Phasellus enim sapien, facilisis sit amet dolor bibendum, viverra faucibus nisl. Cras at enim viverra, ultricies magna non, ultricies ex. Suspendisse nec tincidunt sapien. Duis scelerisque mattis varius. Maecenas auctor egestas ligula. Pellentesque sed erat luctus, facilisis magna in, placerat ipsum. Nam ac pretium mauris. Phasellus fermentum velit eu lectus luctus malesuada. Phasellus pellentesque nisl ac ligula finibus, quis consequat leo iaculis. Nunc mattis fermentum lacinia. Nullam congue id nibh ut sagittis. Nulla mauris ex, dapibus in erat ac, tristique elementum eros. Praesent finibus gravida risus, eu auctor justo aliquet iaculis. Nunc sollicitudin felis at pellentesque lacinia. Aenean vitae lacus a arcu varius finibus. Sed leo urna, placerat vel sagittis efficitur, scelerisque sed magna.",
  "hosts": [
    "Phasellus", 
    "pellentesque nisl ac ligula finibus", 
    ["quis", "consequat", "leo", ["iaculis", "Nunc", "mattis"]],
    "fermentum lacinia. Nullam congue id nibh ut sagittis", 
    "Nulla mauris ex, dapibus in erat ac, tristique elementum eros. Praesent finibus gravida risus, eu auctor justo aliquet iaculis. Nunc sollicitudin felis at pellentesque lacinia."
  ],
  "monitoring_tool": "DataDog.com:the-worst-error-ever-can-you-believe:somebody-better-fix-it:id126596734999746325:server1600767:somehow-this-doesn't-seem-to-be-a-great-option",
  "service": "Purple Spotted Panther Popper 15; Source file: project/panthers/poppers_service.rb#currently_purple_spotted?"
}
title, monitoring tool, service tool, service, description, hosts
Screen_Shot_2020-10-15_at_12.39.33_PM Screen_Shot_2020-10-15_at_12.39.57_PM

Even though these AlertManagement::Alert fields are truncated, the full payload is still available as "details" Screen_Shot_2020-10-15_at_12.51.10_PM

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Edited by Sarah Yasonik

Merge request reports