ceres instances list --output-options InstanceId,Tags

name = 'ceres'
operating_system = 'unix:OSX'
crate_version = '0.0.17'
explanation = '''
Panic occurred in file 'libcore/option.rs' at line 335
'''
method = 'Panic'
backtrace = '''
stack backtrace:
   0:        0x100aec75e - backtrace::backtrace::trace::h3f4dc049cfd9c04a
   1:        0x100aeab9c - backtrace::capture::Backtrace::new::hbf34e349938690c3
   2:        0x1005c5b89 - human_panic::report::Report::new::h595743ae61030f34
   3:        0x1005c7a3a - human_panic::handle_dump::hc277c628265e1b6b
   4:        0x1005b296d - ceres::main::_$u7b$$u7b$closure$u7d$$u7d$::h2223044b292b8b4a
   5:        0x100b095c0 - std::panicking::rust_panic_with_hook::h66872368c6c54afa
   6:        0x100b093ba - std::panicking::begin_panic_fmt::hfc20a126d46a2dce
   7:        0x100b092b2 - rust_begin_unwind
   8:        0x100b52ce5 - core::panicking::panic_fmt::h6c19676a52234f8b
   9:        0x100b52be6 - core::panicking::panic::h348cbec9b9266633
  10:        0x100638d82 - ceres::output::instances::table_output::value_for_field::h06ae72acf291d338
  11:        0x1005e3562 - _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$T$C$$u20$I$GT$$GT$::from_iter::hd01203a5f91f7091
  12:        0x10063835e - _$LT$ceres..output..instances..table_output..TableOutputInstances$u20$as$u20$ceres..output..instances..OutputInstances$GT$::output::h0c43f787f26140da
  13:        0x1006cec2e - _$LT$ceres..modules..instances..list..SubModule$u20$as$u20$ceres..modules..Module$GT$::call::hca4f5e59799d9e78
  14:        0x100709ef3 - _$LT$ceres..modules..instances..SubModule$u20$as$u20$ceres..modules..Module$GT$::call::h8ce12d8106bb8852
  15:        0x100627c50 - ceres::modules::call::heef7027f088d8f52
  16:        0x1005b17cc - ceres::main::h9409cafc5fd01906
  17:        0x1005a8245 - std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h464aca8b46b941b3
  18:        0x100b09217 - std::panicking::try::do_call::hd1b51a136314709e (.llvm.738179016733965576)
  19:        0x100b22e0e - __rust_maybe_catch_panic
  20:        0x100b07181 - std::rt::lang_start_internal::hb7855285a8133f7a
  21:        0x1005b2c9b - main'''

Please release your compiled versions (at least for linux) to easily download new versions without building it by myself

This happens for example when EDITOR=mvim on macOS. Probably there should be an interactive prompt.

ceres --profile staging centerdevice upload --help
ceres-centerdevice-upload
Uploads a document to CenterDevice

USAGE:
    ceres centerdevice upload [OPTIONS] <file>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
        --author <author>               Sets author of document
    -c, --collection <collection>...    Set collection id to add document to
    -f, --filename <filename>           Sets filename of document different from original filename
    -m, --mime-type <mime-type>         Sets the mime type of document; will be guessed if not specified
    -t, --tag <tags>...                 Sets tag for document
        --title <title>                 Sets title of document

ARGS:
    <file>    file to upload

Folgt man der Dokumentation von ceres würde man folgendes Kommando ausführen um eine Datei nach CenterDevice hochzuladen:

ceres --profile staging centerdevice upload --tag 'ceres-upload' 26135397172-1.pdf
error: The following required arguments were not provided:
    <file>

USAGE:
    ceres centerdevice upload <file> --tag <tags>...

For more information try --help

Wie man sieht akzeptiert ceres dieses Kommando nicht. In der Fehlerausgabe erkennt man nun, dass die Datei vor den Options stehen muss. Wenn man das Kommando wie folgt ausführt

ceres --profile staging centerdevice upload 26135397172-1.pdf --tag 'ceres-upload'
INFO  ceres: ceres version=0.0.27, log level=INFO
INFO  ceres: Active profile=staging, default profile=prod
INFO  ceres::modules::centerdevice::upload: Uploading to cloud-wuerstchen.de.
INFO  ceres::modules::centerdevice::upload: Successfully created document with id '32a912d0-33de-0876-9f2f-3689337194d5'.

funktioniert der Upload.

Bitte die Dokumentation für ceres --profile staging centerdevice upload --help anpassen.

Adding a new story with a defined type (bug, feature, chore), name and some text would ne nice.
That would allow creating repetitive standard tickets like backup rotation, certificate renewal etc. in an automated fashion.

It would be very helpful if ceres instances ssh could receive json formatted instance information via stdin, similar to ceres instances run. This probably only makes sense if there is exactly one instance in the input data. In case more than one instance was passed in, an error should be issued.

Datum

this is just a test
XX.XX.XXXX - XX:XX

Umgebung

• IaaS Name: Synaix | AWS
• IaaS Account: Cluster B | prod
• IaaS Environment: prod

Beobachtung

Störungsqualität

• Sichtbarer Ausfall der Anwendung
• Eskalation ins Notfallmanagement

Information an

• #ops
• #cd-core
• #general
• => Notfallmanagement

Analyse

Störungsbeseitigung

Bugtickets in Pivotal

Referenz zu anderen Issues

Schlussfolgerung / nächste Schritte

The Config parser currently requires most of the section to be field even though, they might not be used. The parser should accept that and the modules should take that into consideration

Datum

11.06.2018 - 07:46

Umgebung

• IaaS Name: Synaix
• IaaS Account: Cluster B
• IaaS Environment: prod

Beobachtung

First Responder: Lukas.

• 7:46 - Bosun und Zabbix alamieren über 5-min-Last auf mongodb-m-01; steigt auf bis zu 15. Ursache ist hohe Lese-IO aus mongod. Anwendung wirkt langsam und träge (Webclient, API, Dokumentenverarbeitung).
• 8:34 - Frage in "#ops" nach Ad-hoc Querys wird negativ beantwortet. MongoDB Slowlog zeigt Zugriffe auf Timeline Collection.
• 9:24 - Eskalation ins Notfallmanagement. Slack Call mit Lukas, Patrick, Daniel, Simon und Fuss.

Störungsqualität

• Sichtbarer Ausfall der Anwendung
• Eskalation ins Notfallmanagement

Information an

• #ops
• #cd-core
• #general
• => Notfallmanagement

Analyse

• Timeline Querys, welche vom Desktop Client abgesetzt werden, erfragen Sortierung nach _id. Diese Soriterung veranlasst MongoDB eine ungüstigen Execution Plan zu wählen und vorhandene Indices nicht sinnvoll zu nutzen, so dass über alle Timeline Events seit Freitag itereriert werden muss. Das beinhaltet insbesondere die 4.000.000 Löschevent für CareEnegery.

Störungsbeseitigung

1. Mitigation um 10:19 h: DWH Desktop Clients -- Quelle der meisten Timeline Querys -- werden im LB zurückgewiesen. Keine Veränderung.
2. Mitigation um 10:29 h: /v2/timline wird im LB mit 429 abgelehnt, bestehende Querys in MongoDB gekillt: Last geht spührbar zurück, Anwendung stabilisiert sich.
3. Hotfix wird gebaut, um Index-Hint für MongoDB in diesen Querys hinzuzufügen.

Bugtickets in Pivotal

Referenz zu anderen Issues

Schlussfolgerung / nächste Schritte

ssh-opts should be parsed as [..., "-i", "~/.ssh/ssh-key", ...] and not as [..., "-i ~/.ssh/ssh-key", ...].

INFO  ceres: ceres version=0.0.12, log level=DEBUG
INFO  ceres: Active profile=default, default profile=prod
INFO  ceres::modules::instances::run: Querying description for instances.
INFO  ceres::modules::instances::run: Running commands with progress bar.
i-09307eb67a9f3d230 [0s] ⠉ ssh
DEBUG ceres::utils::command: Executing command 'Command { id: "i-xxxxxxx", cmd: "ssh", args: Some(["-l", "cd-admin", "-i ~/.ssh/ssh-key", "x.x.x.x", "my-command"]), log: "/var/folders/d0/4wy57jg176n265v0dx4kq6z80000gn/T/.tmpMCCqYB", timeout: Some(Duratioi-09307eb67a9f3d230 [0s]   Failed with exit status 255.
INFO  ceres::output::instances::table_output: Outputting only failed result.

For ceres ssh it's parsed correctly.

When filtering with --filter 'InstanceType=t2.*,State=stopped' it is currently not possible to have regular expressions what contain an actual comma. Ceres would interpret it as the beginning of a new filter part.

Possible solution: Allow multiple --filter CLI args to make clear which is which.

Bei meinen ersten Testuploads musste ich zunächst das Log Level für ceres auf INFO stellen, damit ich überhaupt eine document-id angezeigt bekomme.

ceres --profile staging centerdevice upload 26135397172-1.pdf --tag 'ceres-upload'
INFO  ceres: ceres version=0.0.27, log level=INFO
INFO  ceres: Active profile=staging, default profile=prod
INFO  ceres::modules::centerdevice::upload: Uploading to cloud-wuerstchen.de.
INFO  ceres::modules::centerdevice::upload: Successfully created document with id '32a912d0-33de-0876-9f2f-3689337194d5'.

Möchte man ceres nun beispielsweise mit einem technischen Usern benutzen, muss man die Ausgabe mit Tools wie z.B. grep parsen. Hier wäre es sehr hilfreich wenn ceres den Output immer als JSON nach stdout ausgibt.

ceres instances ssh --ssh-opt=-vv --ssh-opt=-i --ssh-opt=~/.ssh/my-key i-XXXXX

This is needed by our Jenkins that have to set a aws session token

Vorfallsprotokoll

Datum: 20.09.2018 - 02:17

Umgebung

• IaaS Name
  • Synaix
  • AWS
• IaaS Account
  • Cluster B
  • prod
• IaaS Environment
  • prod

Erste Meldung

• Alarm: OOM und Mongo State Change, https://bosun.private.prod.prod.aws.internal.cnter.de:8070/incident?id=30439
• Telemetriebeobachtung: __
• Störungsmeldung: __
• Sonstiges: __

First Responder: Lukas Pustina

Vorfallsmanagement

Beobachtung

Bosun meldet um 00:37 Memory Pressure auf mongodb-m-02 in Cluster B und um 2:17 einen OOM Kill sowie Degregation von Replicaset 02.

Bewertung der Störung

Kein Problem für uns. Das Mongo Cluster hat mit 2 Instanzen weiter gearbeitet, so dass es zu keiner Beeinträchtigung der Verfügbarkeit kam.

Störungsqualität

• Kreis der Betroffenen
  • Einzelne User
  • Mandanten
  • Distributoren
  • Alle
  • Sonstige: __
• Zeitdauer der Störung: 5h
• Sichtbarer Ausfall der Anwendung
  • Ja
  • Nein

Eskalation ins Notfallmanagement

• Wurde die Verfügbarkeit länger als 10 min nicht mehr erbracht?
• Wurde die Vertraulichkeit von Kundendaten (Dokumente oder Metadaten) verletzt?
• Wurde die Integrität von Kundendaten (Dokumente oder Metadaten) verletzt?

Falls die Verfügbarkeit, Vertraulichkeit oder Integrität beeinträchtigt wurde, muss der Vorfall ins Notfallmanagement eskaliert werden -- siehe "Verfahren zum Vorfallsmanagement".

Kommunikation

Intern

• #ops
• #cd-core
• #general
• => Notfallmanagement

Extern über Statusseite

• Cluster B
• AWS

Analyse

Siehe Beobachtung. Interessant ist, dass Upstart den Process bzw. Dienst mongo-replicaset-02 nicht automatische wieder gestartet hat.

Störungsbeseitigung

Um 07:00 habe ich die MongoDB Insanz von Hand wieder gestartet. Telemetrie hat wenige Minuten später "grün" gemeldet.

Abschluss des Vorfalls

Protokoll

• Protokoll vollständig ausgefüllt?
• Labels am Ops Issue gesetzt?
• Protokoll nach Vier-Augen-Prinzip (Review) geprüft?
• Beendigung der Störung kommuniziert?

Referenz zu anderen Vorfällen (Ops-Issues)

Schlussfolgerungen

Bugtickets in Pivotal

nächste Schritte

Bei Gelegenheit das Upstart Log prüfen. Ist aber nicht dringend.

Bewertung des Vorfallsbehandlung

• War die Vorfallsbehandlung angemessen? Ja.
• Was können wir beim nächsten Vorfall (dieser Art) besser machen? -
• Wie können wir solche Vorfälle in Zukunft vermeiden? Upstart sollte den Dienst automatisch neustarten.

cf. issue #93