Sidehistorik
| Tip |
|---|
This is a POC for using JIRA as a CMDB
An Issue is a "Configuration" item like a server, laptop, MySQL Database etc. |
| Info |
|---|
Why?
Well, most of the (seen from a ITIL Service Operation view) data is actually in JIRA, this is Incidents, Changes and Service Requests... Secondly, JIRA can be seen as a mere Form/workflow control system |
| Indholdsfortegnelse |
|---|
Architechture
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
| Indholdsfortegnelse |
|---|
...
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
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)
validity, quality and maintenance
JIRA has strict fields
JIRA has versioning on all field changes (history)
JIRA field can by updated by GUI and programmatically (CLI, RCP, SOAP)
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 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 Or: https://marketplace.atlassian.com/plugins/com.consultingtoolsmiths.jira.plugins.createandlink
Data
...
out
Data can be extracted/fed out 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
SQL Quiries
Simplifying data from scripts
Field-values updated Field/Values opdateres samlet via CLI:
| Kodeblok |
|---|
jira.sh --action setFieldValue --issue "CMDB-4" --field "Memory" --values "1024 MB" jira.sh --action setFieldValue --issue "CMDB-4" --field "VM Version" --values "9" |
| Advarsel |
|---|
The CLI only supports updating 2 fields in one call, hence 4 field will required 2 calls - and (possible) 2 notifications fired |
Sanity Checks
Jo flere datakilder, jo bedre mulighed for at køre sanity checks (Data korrekthed /integritet), f.eks:
We want to make a reverse check to make sure data is sane:
- Is Virtual Center attributes aligned with 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
- Is Monitoring data correct with Virtual Center Tags
- Is the server in the Financial systems (for invoicing)
- Is monitoring data coffect with monitoring system
Rapporting
Watchers on the Configuration Item (Issue)Watchers for server changes
Daily summary: https://confluence.atlassian.com/display/JIRA/Receiving+a+Daily+Summary+of+Updated+Issues
Screenshots
Dashboard
...
Configuration Item (sample for a server)
Link til opgaver/eventsLinks to events / tasks / incidents:
Virtual Center Data:
Service / Support data:
MonitoreringsbeskrivelseMonitoreringdata:
¨
Workflow/Lifecycle
A server (or other Configuration Item) can have a conbtrolled controlled lifecycle (implemented as a workflow):
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Challenges
Issues kan have server/object-name as Ident
...
Does not work: issuetype=server and (Memory changed after startOfWeek("-1") before startOfWeek())"
Screenshots
...
Test
Tests
Updating field(s) with no changesOpdatering af flere felter på en gang, hvor ingen er ændret (der understøttes kun 2 felter pr. gang):
| Kodeblok |
|---|
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
Hence, the CLI/JIRA takes care of changes and ignores no changes.
Updating field(s) with changes;Opdatering af flere felter på en gang, hvor et af flere er ændret:
| Kodeblok |
|---|
spiderman:atlassian-cli npn$ ./change-serverfields.sh Issue CMDB-4 updated. spiderman:atlassian-cli npn$ |
Ideer
Alle mulige metadaa
Hence, the issue is updated.
Ideas
Metadaa
- Scan servers for all Scan for alle *.sh og and *.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:
| Advarsel |
|---|
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)
| Gliffy Diagram | ||
|---|---|---|
|
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
- files and save in JIRA field - for reference/documentation/searchability
- Save crontab for all servers in JIRA field - for reference/documentation/searchability
Script information
Its an option to put more control into the update-scripts:
| Advarsel |
|---|
This introduces added complexibility and logic outside JIRA. |
Flow for updating every value:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|