Nightingale v9 System Integration: embed any external system (CMDB, Wiki, internal BI, Grafana, etc.) into the Nightingale sidebar as an iframe, with no tab switching and a unified entry.
Overview
System Integration = embed external web systems into Nightingale’s sidebar via iframe, letting SRE/ops engineers complete the full flow from monitoring alerts to CMDB host lookups to Wiki SOP review in a single browser tab.
Sidebar path: Integration Center → System Integration, URL /embedded-products.
Use cases:
- Embed internal CMDB / ticketing — after receiving an alert, directly open in the Nightingale sidebar to check asset ownership;
- Embed team Wiki troubleshooting Runbooks — one-click SOP steps during incident response;
- Embed existing Grafana dashboards — reuse them without migration;
- Embed internal approval/change systems — one-click mute request during maintenance windows.
After integration:
- A new link (e.g. “Test System A”) appears at the bottom of the sidebar; clicking loads the iframe in the main area;
- One-click copy of Nightingale login state / cookie info (if the other system supports it), for seamless cross-system login.
Create System Integration
| Field | Required | Description |
|---|---|---|
| Name | Yes | Menu name shown in the sidebar; keep it short (≤ 6 chars), e.g. CMDB, Wiki, Ticket |
| Link | Yes | Full URL to embed, e.g. https://cmdb.intra.example.com/dashboard |
| Visibility | Yes | Two choices: Logged-in users visible (all logged-in Nightingale users can see), Specific teams visible (only selected teams can see, for permission isolation) |
After submission, the entry appears at the bottom of the sidebar immediately (may need a refresh).
Extra Operations in the List
- Show in menu toggle: each row has an “Is shown in menu” switch — when off, the integration still exists but doesn’t show in the sidebar; useful for temporary takedown while preserving config.
- Drag sorting: the
☰icon at the row start can be dragged to adjust the display order in the sidebar. - Edit / Delete: standard operations.
Cross-origin & iframe Security: Must Read
Whether an external system can be embedded depends on its response headers; Nightingale is just an iframe container:
| Response header | Outcome |
|---|---|
X-Frame-Options: DENY or SAMEORIGIN |
Browser forcibly rejects embedding, iframe shows blank |
Content-Security-Policy: frame-ancestors 'self' |
Same, browser rejects |
| Neither set / set to allow | Can be embedded |
If the embedded target page is blank / all white, 90% it’s the other side not allowing iframe embedding. Two fixes:
- Modify the other side’s response header: have their ops add
Content-Security-Policy: frame-ancestors https://your.nightingale.domain/; - Run a local reverse proxy: use nginx to reverse proxy the other site, override the response header at the proxy layer, and fill in the proxy URL.
The same limitation includes Cookie SameSite: many systems’ login state cookies are
SameSite=Lax/Strict, and cross-site iframes will not carry cookies, causing users to see the login page in the iframe. Have the other side’s ops switch toSameSite=None; Secure, or use OIDC/SSO for unified login.
FAQ
Q1: Page is all white / shows “refused to connect” after embedding
A: See the “Cross-origin & iframe Security” section above; first check the Chrome DevTools Console for errors. Common error messages:
Refused to display ... in a frame because it set 'X-Frame-Options' to 'sameorigin': the other side’s X-Frame-Options is too strict, have them change it;Refused to frame ... because an ancestor violates the following Content Security Policy directive: frame-ancestors: the other side’s CSP restriction, add the Nightingale domain to the frame-ancestors allowlist;- Long spinning, eventually timeout: the other side’s website itself is slow, unrelated to Nightingale.
Q2: The embedded system requires login, jumping to the login page can’t return to Nightingale — what to do?
A: Login redirects inside the iframe usually open only inside the iframe and don’t pollute the outer Nightingale. But many old systems’ login pages have anti-iframe detection and force jump out. Pragmatic approaches:
- Connect the internal SSO (company unified login) to both Nightingale and the embedded system for single sign-on;
- Or have the embedded system provide “anonymous read-only access” or “IP-allowlist-based” login-free mode.
Q3: Should the embedded page be protected? Can anyone see it?
A: Use “Visibility” to control. If the embedded system is sensitive (CMDB, change platform), strongly recommend selecting “Specific teams visible” and only adding the ops/SRE team. Also recommend the embedded system itself does permission checking (based on login state / OAuth) — don’t rely on Nightingale’s “visibility” as the security boundary, because users with the URL can access the other system directly and Nightingale can’t intervene.
Q4: Can users click links in the embedded page to navigate away?
A: Yes. Links clicked in iframe open in the iframe by default; if the other side uses target="_top", it will jump out of the iframe entirely — and the user actually leaves the Nightingale site. If you care, have the other side’s ops change target to _self.
