POC tager udgangpunk i et CI for en server, men man kan lave flere typer af CI'er
POC henter ikke data fra andre systemer, men Netic har øvelse i at bruge Atlassian CLI mod JIRA
Arkitektur
Fejl ved rendering af macro 'gliffy'
java.lang.IllegalArgumentException: Content must not be null
Datagrundlag / Data
Stringente felter - mere end Docs
Versionering på alle rettelser
Tabbed indput:
Fields / Links til CMDB fra andre JIRA Sager - her virker lookup på hostnavn (Summary felt)
Alternativ til linking kan være en (multi)select felt i JIRA med servernavne, evt. via Kepler DB Lookup - https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.databasecf
Eller start task'en fra CMDB Item'et : https://marketplace.atlassian.com/plugins/com.consultingtoolsmiths.jira.plugins.createandlink
Data ud
Data kan fødes til andre systemer eller visuelt bl.a. via:
JIRA XML/RSS Feeds
Atlassian CLI
Netic's XML2HTML Projekt
Simplificering af scripts
Ingen mellem Database lag hvor vi skal holde styr på States
Atlassian CLI til JIRA
Field/Values opdateres samlet via CLI:
jira.sh --action setFieldValue --issue "CMDB-4" --field "Memory" --values "1024 MB" jira.sh --action setFieldValue --issue "CMDB-4" --field "VM Version" --values "9"
Sanity Checks
Jo flere datakilder, jo bedre mulighed for at køre sanity checks (Data korrekthed /integritet), f.eks:
- Passer VC folder (produktion, other, disabled) med JIRA State ?
- Er der NetVault eller rsync data - i forhold til objektets servicemål/state
- Passer Zenoss Group (servicemål) med VC Data
- Passer Zenoss Data med objektets data
- Findes servernavn i Navision hvis Servicemål > Bronze?
- Har vi alle maskiner hvis Servicemål > Bronze i Zenoss?
Rapporting
Watchers for server changes
Daily summary: https://confluence.atlassian.com/display/JIRA/Receiving+a+Daily+Summary+of+Updated+Issues
Screenshots
Dashboard
Item (sample for a server)
Link til opgaver/events:
Virtual Center Data:
Service / Support data:
Monitoreringsbeskrivelse:
¨
Workflow/Lifecycle
A server (or other Configuration Item) can have a conbtrolled lifecycle (implemented as a workflow):
Fejl ved rendering af macro 'gliffy'
java.lang.IllegalArgumentException: Content must not be null
Challenges
Issues kan have server/object-name as Ident
Summary can be non-unique (e.g. 2 Configuration Items with same name can be created)
Does not work: issuetype=server and (Memory changed after startOfWeek("-1") before startOfWeek())"
Screenshots
Test
Opdatering af flere felter på en gang, hvor ingen er ændret (der understøttes kun 2 felter pr. gang):
spiderman:atlassian-cli npn$ ./change-serverfields.sh There are no field values changed by the parameters specified. Issue CMDB-4 not changed. spiderman:atlassian-cli npn$
Altså kan man bare opdatere løs UDEN at bekymre sig om felterne faktisk er ændret
Opdatering af flere felter på en gang, hvor et af flere er ændret:
spiderman:atlassian-cli npn$ ./change-serverfields.sh Issue CMDB-4 updated. spiderman:atlassian-cli npn$
Ideer
Alle mulige metadaa
- Scan for alle *.sh og *.log filer på et server - gemme i et felt for søgbarhed
- Gemme crontabs for alle servere
Notification
Da Notificationer i JIRA desværre ikke er pr. felt, men ved en update af et issue, kan det generere mange unødvendige mails; derfor er der flere alternativer til notifikation
Script information
Kontrol m.v. lægges ud i script:
Ulempen ved dette er øge script komplexitet og logik uden for JIRA. Primært må targert derfor evt. være ting der faktisk ændrer faktureringer
Flow for opdatering af værdier; for hver Attribut (Indeholdende en VÆRDI)
Splunk Rapport
Da vi opsamler ændringer fra JIRA's "ChangeItems" Tabel, vil du også være muligt at lave en rapport i Splunk, der blot filtrerer på rettelser i visse felter i visse JIRA typer.
ChangeItems udtræk
Det er mulig simpelthen at udtrække SQL direkte fra "ChangeItems" tabellen og parse det for f.eks RAM, CPU, DISK ændringer og sende mail eller oprette JIRA SALGssag på det