The is a POC for using JIRA as a CMDB
Architechture
Data
JIRA has strict fields
JIRA has versioning on all field changes
Tabbed input:
Fields / Links to Configuration Items from/to other JIRA Issues - Hostname lookup on the Summary field works
an alternative to linking could be a (multi)select field on issues in JIRA - like Kepler DB Lookup - https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.databasecf
Or: https://marketplace.atlassian.com/plugins/com.consultingtoolsmiths.jira.plugins.createandlink
Data out
Data can be extracted /fed out via:
JIRA XML/RSS Feeds
Atlassian CLI
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):
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