Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

Scaleway till Slack: direkt serveruppslag

Rickard Andersson Partner, Nodenordic.se

Under en incident är den värsta känslan att veta att svaret finns ”någonstans i Scaleway-konsolen”… och ändå lägga 10 minuter på att klicka runt mellan zoner, instanser och baremetal för att hitta den enda server du faktiskt behöver.

Det här problemet med Scaleway Slack lookup drabbar DevOps-ansvariga först, men jourhavande sysadmins och även någon enstaka engineering manager känner av det också. Du vill ha ett snabbt, konsekvent sätt att identifiera rätt maskin via tagg, namn, publik IP eller zon, och sedan dela resultatet utan att behöva skriva om det tre gånger.

Det här arbetsflödet gör en enkel POST-förfrågan till en strukturerad serverträff som du kan klistra in direkt i Slack, vilket innebär färre konsolrundor och tydligare incidentuppdateringar. Nedan ser du vad det gör, vad du behöver och hur du anpassar det till din miljö.

Så fungerar automatiseringen

Hela n8n-arbetsflödet, från trigger till slutlig output:

n8n Workflow Template: Scaleway till Slack: direkt serveruppslag

Problemet: serveruppslag tar tid när snabbhet är avgörande

Att slå upp ”rätt server” låter enkelt – tills det inte är det. I Scaleway har du ofta flera zoner, en mix av instanser och baremetal, och namngivningsstandarder som var ”tillräckligt bra” för sex månader sedan. Så du söker på namn, sedan söker du på tagg, sedan korscheckar du en IP någon klistrade in i Slack, och sedan inser du att du var i fel zon. Under tiden fortsätter incidentkanalen att rulla och din uppdatering är redan inaktuell.

Det summerar snabbt. Och problemet handlar inte bara om tid, utan om tillförlitlighet under press.

  • Du gör ofta samma uppslag två gånger eftersom någon ber om ”bara IP:t” eller ”bara zonen” efter att du redan har postat en skärmbild.
  • Manuell filtrering blir inkonsekvent, så två personer kan ”hitta” olika servrar för samma förfrågan.
  • Konsolnavigering är långsam när du hoppar mellan instanser och baremetal över flera zoner.
  • Incidentuppdateringar tappar tydlighet eftersom detaljerna (status, typ, taggar) inte delas i ett prydligt, repeterbart format.

Lösningen: fråga Scaleway en gång och få en strukturerad träff att dela i Slack

Det här n8n-arbetsflödet fungerar som en ”server lookup-endpoint” för teamet. En webhook tar emot en enkel JSON-payload med två fält: vad du vill söka på (taggar, namn, public IP eller zon) och värdet du vill söka efter. Därifrån hämtar arbetsflödet serverinventeringar från Scaleways API över dina konfigurerade zoner för både instanser och baremetal, och normaliserar sedan de råa API-svaren till en konsekvent struktur. Därefter skickar det resultaten genom rätt filter baserat på din input så att du bara får tillbaka matchande servrar. Slutligen svarar det direkt med en strukturerad JSON-array (eller ett hjälpsamt fel), som du kan vidarebefordra till Slack, bifoga i en incidentuppdatering eller mata in i en annan automation.

Arbetsflödet startar med ett autentiserat webhook-anrop. Sedan loopar det igenom din zonlista, hämtar inventering för instanser och baremetal, transformerar allt till ett standardiserat ”serverinfo”-format och kör ett riktat filter. Du får svaret i ett svar, redo att dela.

Det du får: automation vs. resultat

Exempel: så här ser det ut i praktiken

Säg att teamet kör i 6 zoner och att ni använder både instanser och baremetal. Manuellt betyder en kontroll som ”hitta servern via IP” ofta att du öppnar konsolen, byter zon några gånger och sedan kollar i den andra produktvyn, vilket lätt blir runt 5 minuter per zon när du räknar in kontextbyten (ungefär 30 minuter). Med det här arbetsflödet skickar du en förfrågan (eller låter Slack skicka den), väntar på att API-anropen blir klara och får tillbaka en filtrerad lista på cirka en minut. Det är ungefär en halvtimme ner till ”kopiera svaret och klistra in”.

Det du behöver

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Scaleway API för att hämta inventering för instanser och baremetal
  • Slack för att dela uppslagsresultat i era kanaler
  • Scaleway API-token (hämta den i Scaleway Console → API keys)

Kunskapsnivå: medel. Du klistrar in en API-token, sätter zonlistor och testar en webhook-förfrågan med basic auth.

Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

En autentiserad webhook tar emot din uppslagsförfrågan. Du skickar search_by (tags, name, public_ip eller zone) plus search-värdet. Basic authentication skyddar endpointen så att vem som helst inte kan inventera din infrastruktur.

Din input mappas och zonlistan förbereds. n8n normaliserar inkommande fält och bryter sedan ut zonkonfigurationen så att den kan iterera snyggt över flera Scaleway-regioner.

Scaleway-data hämtas och transformeras. Arbetsflödet loopar igenom zoner, anropar Scaleway API för instanser och (när det är tillämpligt) baremetal, och kör sedan ett transformeringssteg så att båda datakällorna ser likadana ut för resten av arbetsflödet.

Rätt filter körs och ett svar returneras. Ett routningssteg skickar den aggregerade listan till rätt filtreringsrutin, och n8n svarar med antingen matchningarna, den ofiltrerade listan eller ett tydligt felmeddelande som du kan visa i Slack.

Du kan enkelt ändra zonlistorna så att de matchar din faktiska footprint och sedan routa slutsvaret till Slack (eller e-post) efter behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementation

Steg 1: konfigurera webhook-triggern

Det här arbetsflödet startar när ett externt system skickar en POST-förfrågan till den inkommande webhooken och returnerar resultat via response-noder.

  1. Lägg till en Incoming Webhook Trigger-nod och ställ in HTTP Method till POST.
  2. Ställ in Path till a6767312-3a4c-4819-b4fe-a03c9e0ade5c.
  3. Ställ in Response Mode till responseNode så att response-noderna kan returnera nyttolasten.
  4. Inloggningsuppgifter krävs: Anslut era httpBasicAuth-uppgifter i Incoming Webhook Trigger.

Steg 2: anslut Scaleway-indata och zonlistor

Fånga filterindata och definiera Scaleway-zonerna som ska frågas innan ni delar upp dem i enskilda objekt.

  1. I Map Input Fields, ställ in search_by till {{ $json.body.search_by }} och search till {{ $json.body.search }}.
  2. I Map Input Fields, ersätt Scaleway-X-Auth-Token-värdet [CONFIGURE_YOUR_API_KEY] med er Scaleway API-nyckel.
  3. Behåll ZONE_INSTANCE som arrayen ["fr-par-1", "fr-par-2", "fr-par-3", "nl-ams-1", "nl-ams-2", "nl-ams-3", "pl-waw-1", "pl-waw-2", "pl-waw-3"].
  4. Behåll ZONE_BAREMETAL som arrayen ["fr-par-1", "fr-par-2", "nl-ams-1", "nl-ams-2", "pl-waw-2", "pl-waw-3"].
  5. I Split Zone List, ställ in Field To Split Out till ZONE_INSTANCE för att bearbeta varje zon individuellt.
  6. Verifiera att Split Zone List flödar in i Iterate Zones för att starta per-zon-loopen.
⚠️ Vanlig fallgrop: Om ni lämnar [CONFIGURE_YOUR_API_KEY] i Map Input Fields kommer alla Scaleway-anrop att misslyckas med autentiseringsfel.

Steg 3: sätt upp zoniterering och Scaleway API-anrop

Det här steget loopar igenom zoner, hämtar compute- och baremetal-servrar och avgör om baremetal-uppslag behövs.

  1. I Iterate Zones, behåll standardinställningarna för att batcha igenom den uppdelade zonlistan.
  2. I Fetch Instance by Zone, ställ in URL till =https://api.scaleway.com/instance/v1/zones/{{ $('Split Zone List').item.json.ZONE_INSTANCE }}/servers.
  3. I Fetch Instance by Zone, ställ in headers: X-Auth-Token till {{ $('Map Input Fields').item.json['Scalway-X-Auth-Token'] }} och Content-Type till application/json.
  4. I Check Baremetal Zone, bekräfta att villkoret använder att {{ $('Map Input Fields').item.json.ZONE_BAREMETAL }} innehåller {{ $('Iterate Zones').item.json.ZONE_INSTANCE }}.
  5. I Fetch Baremetal by Zone, ställ in URL till =https://api.scaleway.com/baremetal/v1/zones/{{ $('Split Zone List').item.json.ZONE_INSTANCE }}/servers och återanvänd samma header-värden som för instance-anropet.
Tips: Körordningen är Split Zone ListIterate ZonesFetch Instance by ZoneCheck Baremetal ZoneFetch Baremetal by ZoneIterate Zones.

Steg 4: normalisera serverdata och routa filter

Serverdata normaliseras och routas sedan baserat på den begärda filtertypen.

  1. I Transform Server Data, behåll JavaScript-logiken som extraherar name, tags, public_ip, type, state, zone och user.
  2. Koppla Iterate Zones till Transform Server Data så att varje batch bearbetas innan filtrering.
  3. I Route Filter Type, säkerställ att varje regel använder {{ $('Map Input Fields').first().json.search_by }} och rätt värden: tags, name, public_ip, zone och null.
  4. Bekräfta flödet Transform Server DataRoute Filter Type, och vidare till respektive filternod.
Tips: Fallback-utgången i Route Filter Type är satt till extra och är kopplad till Return Error Response om filtret är ogiltigt.

Steg 5: konfigurera filter och response-noder

Filternoderna begränsar resultaten efter tagg, namn, IP eller zon och svarar via webhookens response-noder.

  1. I Filter by Tags, behåll filteruttrycket som kontrollerar {{ $('Map Input Fields').first().json.search }} i server.json.tags.
  2. I Filter by Name, behåll filteruttrycket som kontrollerar {{ $('Map Input Fields').first().json.search }} i server.json.name.
  3. I Filter by Public IP, behåll filteruttrycket som kontrollerar {{ $('Map Input Fields').first().json.search }} i server.json.public_ip.
  4. I Filter by Zone, behåll filterlogiken som angivet (observera att den för närvarande kontrollerar public_ip mot sökningen).
  5. Koppla filternoderna till deras response-noder: Filter by TagsSend Tag Results, Filter by NameSend Name Results, Filter by Public IPSend IP Results, Filter by ZoneSend Zone Results.
  6. Säkerställ att Send Unfiltered Results är kopplad till regeln i Route Filter Type som matchar null.
  7. Behåll Return Error Response med Response Body satt till { "error": "no search by {{ $('Map Input Fields').item.json.search_by }} available. You can search by : tags, name, public_ip, zone" }.
⚠️ Vanlig fallgrop: Filter by Zone söker för närvarande på public_ip, inte zone. Uppdatera dess JavaScript om ni avser riktig zonfiltrering.

Steg 6: konfigurera verktygsuppslagning (valfritt)

Verktygsgrenen kan anropa en annan webhook för att begära parametrar för serveruppslag och iterera igenom dem.

  1. I Utility: Invoke Server Lookup, ställ in URL till https://sup-n8n.unipile.com/webhook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx och Method till POST.
  2. Inloggningsuppgifter krävs: Anslut era httpBasicAuth-uppgifter i Utility: Invoke Server Lookup.
  3. Behåll body-parametrarna: search_by och search för att styra uppslagsförfrågan.
  4. Bekräfta flödet Utility: Invoke Server LookupUtility: Iterate Items om ni planerar att använda den här grenen.

Steg 7: testa och aktivera ert arbetsflöde

Validera webhooken, säkerställ att Scaleway-anropen lyckas och aktivera därefter arbetsflödet för produktion.

  1. Använd test-URL:en för Incoming Webhook Trigger för att skicka en POST-body med search_by och search.
  2. Verifiera att Transform Server Data skickar ut normaliserade serverobjekt och att ett svar returneras via rätt Send ... Results-nod.
  3. Bekräfta att körningen lyckas genom att kontrollera webhookens response body för serverposter (eller JSON-felet från Return Error Response om den är ogiltig).
  4. När allt är validerat, slå på arbetsflödet till Active för produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Scaleway API-uppgifter kan gå ut eller sakna rätt behörigheter. Om det slutar fungera: kontrollera din token i området ”Edit Fields (Set)” och bekräfta först i Scaleway Console att nyckeln fortfarande är giltig.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera outputs för alltid.

Vanliga frågor

Hur lång tid tar det att sätta upp den här Scaleway Slack lookup-automationen?

Cirka 30 minuter om du redan har din Scaleway-token och zonerna till hands.

Behöver jag kunna koda för att automatisera Scaleway Slack lookup?

Nej, ingen kodning krävs. Du klistrar främst in uppgifter, justerar zonlistor och testar ett par webhook-förfrågningar.

Är n8n gratis att använda för det här Scaleway Slack lookup-arbetsflödet?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna med Scaleway API-användning (oftast försumbar för enkla inventeringsuppslag).

Var kan jag hosta n8n för att köra den här automationslösningen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverdrift.

Kan jag anpassa det här Scaleway Slack lookup-arbetsflödet för att posta direkt i Slack?

Ja, men då lägger du till ett extra steg. Behåll befintligt webhook-svar för API-användare och lägg sedan till en Slack message-action efter den filterväg du bryr dig om (till exempel efter ”Filter by Public IP”). Vanliga anpassningar är att formatera outputen som ett kort Slack-vänligt block, bara returnera servrar som är ”running” och tagga en kanal baserat på zon.

Varför misslyckas min Scaleway-anslutning i det här arbetsflödet?

Oftast beror det på en ogiltig eller utgången Scaleway API-token. Skapa en ny token i Scaleway Console och uppdatera den där arbetsflödet sätter autentiseringsheadern (noden ”Edit Fields (Set)” är den vanligaste platsen). Om tokenen är okej, kontrollera att dina zoner stämmer, eftersom en felaktig zon kan se ut som ”no data” och ge förvirrande tomma resultat. Rate limiting är ovanligt för det här användningsfallet, men om du bombar endpointen under ett avbrott kan det hända.

Hur många servrar klarar den här Scaleway Slack lookup-automationen?

Några tusen servrar är inga problem för de flesta upplägg, eftersom det i praktiken bara är API-hämtning + filtrering, och du kan alltid self-hosta n8n för att skala antalet körningar utifrån din serverkapacitet.

Är den här Scaleway Slack lookup-automationen bättre än att använda Zapier eller Make?

För det här användningsfallet är n8n oftast ett bättre val, eftersom du gör insamling via API över flera zoner, förgreningar och datanormalisering i en och samma körning – och de plattformarna blir snabbt klumpiga (och dyra) när flödet inte är en enkel trigger/action i två steg. n8n ger dig också möjlighet att self-hosta, vilket spelar roll om du vill ha obegränsade interna uppslag och bättre kontroll över credentials. Zapier eller Make kan ändå fungera om du bara någonsin frågar en zon och inte bryr dig om hur svaret formas. Om du vill ha Slack-anpassad formatering, fallback-beteenden och skyddsräcken som allowlists för zoner håller n8n sig läsbart när det växer. Prata med en automationsexpert om du vill ha hjälp att välja.

När detta väl rullar blir serveridentifiering en vana som tar ett meddelande, inte ett miniprojekt i konsolen. Arbetsflödet hanterar de repetitiva uppslagen så att dina incidentuppdateringar förblir snabba och trovärdiga.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal