Giter Club home page Giter Club logo

opsgenie-integration's Introduction

OpsGenie Integration

The project includes OpsGenie's specific integration packages:

  • icinga
  • icinga2
  • nagios
  • nagiosxi
  • netcool
  • redmine
  • zabbix
  • zendesk
  • zenoss
  • oem

Build

Requirements:

  • JDK 1.7 (to compile only)
  • A clone of OpsgenieClient project into same parent directory.
  • Go (required only for netcool package)

Tasks

Available tasks

  • packageSdk: Packages sdk as zip file that includes jars, javadoc and third_party under build/distributions

  • package<Integration_name>: Packages the integration specific rpm, deb or zip files.

  • package<Integration_name>Zip: Packages the integration's zip archive only if available

  • package<Integration_name>OS: Packages the integration's rpm and deb archives only if available

  • packageAll: Packages all zip, rpm and rpm archives for all integrations. Also includes Go based Lamp client tool zip package(if you checked out go based lamp locally) (requires Go to be installed and GOPATH env variable to be set).

  • packageLamp: If you checked out Go Based Lamp to your local computer, you can generate a zip package of it (requires Go to be installed and GOPATH env variable to be set). You can find the Go Based Lamp source code from here

You can run the tasks:

Unix: ./gradlew packageRedmine packageSdk packageNagios

Windows: gradlew.bat packageRedmine packageSdk packageNagios

Or if you want to package all

Unix: ./gradlew packageAll

Windows: gradlew.bat packageAll

opsgenie-integration's People

Contributors

akyuznurettin avatar allencraigbarnard avatar autodon avatar berkay avatar bkaganyildiz avatar bmlaz avatar bneqld avatar celalemre avatar cemkucuk avatar cglrkn avatar emelkomurcu avatar erenkizilay avatar espenas avatar faziletozer avatar halitokumus avatar internetstaff avatar ktgulsoy avatar meralbusratekinsen avatar metehanozturk avatar metehanyildirimops avatar mhamzak008 avatar omerozkan avatar ozlemmcokuk avatar samoxive avatar tlgkk avatar tubaozturk avatar tubaozturk92 avatar ufukoz avatar uraviog avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opsgenie-integration's Issues

Zabbix `send2opsgenie` does not set correct priority with trigger severity

In the Zabbix, I have configured action operation to pass triggerSeverity='{TRIGGER.SEVERITY}' as per instruction.

/home/opsgenie/oec/opsgenie-zabbix/send2opsgenie -triggerName='{TRIGGER.NAME}' -triggerId='{TRIGGER.ID}' -triggerStatus='{TRIGGER.STATUS}' -triggerSeverity='{TRIGGER.SEVERITY}' -triggerDescription='{TRIGGER.DESCRIPTION}' -triggerUrl='{TRIGGER.URL}' -triggerValue='{TRIGGER.VALUE}' -triggerHostGroupName='{TRIGGER.HOSTGROUP.NAME}' -hostName='{HOST.NAME}' -ipAddress='{IPADDRESS}' -eventId='{EVENT.ID}' -date='{DATE}' -time='{TIME}' -itemKey='{ITEM.KEY}' -itemValue='{ITEM.VALUE}' -recoveryEventStatus='{EVENT.RECOVERY.STATUS}'

However, in the Opsgenie, all the alert from Zabbix became P3-Moderate.

Should I configure something else or did I misconfigure?

Task.leftShift has been deprecated

I tried to compile in Debian 10. I needed to manually edit almost all the scripts to remove the "<<" statement and replace it by "doLast()"
On top, in Gradle 5. you can no longer directly execute a task. I therefore made task depend on each other so they get executed. I am not certain it is the right way, but I'd like to submit a pull request so at least the work of manually replacing the "<<" can be kept.

Service Cloud integration is not "bulkified"

Hey,

I'm struggling a bit with the implementation of the APEX trigger in the Service Cloud integration.
https://github.com/opsgenie/opsgenie-integration/blob/master/salesForceServiceCloud/opsgenieTrigger.apxt

Salesforce best practice for triggers is to "bulkify" them, that is, write them to expect from 1 - 200 records at once. See: Best Practice: Bulkify Your Code.

OpsGenie's implementation only addresses Trigger.new[0] - the first record in a set that could possibly contain 200 cases. With this implementation, the rest of the records would be ignored and not sent to OpsGenie.

Possible solutions:

Wrap the existing implementation in a loop.

for(Case cse : Trigger.new)
{
	Case obj = cse;
	string id=obj.Id;
	// etc...
	opsgenieClass.xRESTCall(endpoint, payload);
}

The major problem with this is the HTTP callout at the end, which would be executed up to 200 times dependent on the number of cases passed into the trigger. The first issue is simply the amount of time this would take to process. The second issue is that a single APEX transaction can make a maximum of 100 callouts, whereas the trigger could accept up to 200 records. Hitting the callout limit would cause the entire insert/update transaction to fail and rollback.
See: Callout Limits and Limitations

"Bulkify" your REST endpoint.

// create a list to hold our payloads
List<String> payloads = new List<String>();

// iterate over the cases
for(Case cse : Trigger.new)
{
	Case obj = cse;
	string id=obj.Id;
	// etc...

	string payload= '{'+
	// etc...
	'}';

	// add the payload to the list
	payloads.add(payload);
}

// combine the payloads into a single string
String combinedPayload = '[' + String.join(payloads, ',') + ']';

// now a single call, outside the loop
opsgenieClass.xRESTCall(newEndpoint, combinedPayload);

This is the best option. Leave the current endpoint as is, so existing implementations don't break. Create a new endpoint that accepts a JSON array so that Salesforce can pass up to 200 payloads in a single call.

Forward Zabbix Tags to OpsGenie

Hi,
not sure if this is already possible, but it would be cool if Zabbix tags defined with a trigger could be forwarded to OpsGenie as it would make ruling much easier.

Dragging 'Tags' into any field in the Integrations form adds '{{tags}}' and looking at zabbix2opsgenie.go, it seems like a parameter named 'tags' is indeed supported.

But the actionCommand.txt does not mention it.

Thanks,
Sven

Cannot authenticate on EU instance of Opsgenie

I cannot get lamp to work with an account on the EU instance. Any request ends up with Client error occurred; Response Code: 401, Response Body: {"message":"Could not authenticate","took":0.0,"requestId":"โ€ฆ"}.

Because there is no mention of the existence of two API endpoints in the docs or in the configuration I am wondering if it is because all requests go to https://api.opsgenie.com/ instead of
https://api.eu.opsgenie.com/ as documented here: https://docs.opsgenie.com/docs/api-overview

Nagios plugin TLS mutual auth support

Is TLS mutual authentication supported by the nagios integration plugin?

I currently run nagios 3.5.1 with SSL authentication under apache 2.4 with SSLVerifyClient require and I can't seem to get the nagiosActionExecutor to present my client certificate in the ssl handshake with apache when performing a nagios action.

I've installed v2.19.0 of opsgenie-nagios:

$ dpkg -s opsgenie-nagios
Package: opsgenie-nagios
Status: install ok installed
Priority: extra
Section: default
Installed-Size: 27997
Maintainer: OpsGenie
Architecture: all
Version: 2.19.0
<!-- snip -->

I am running marid with the following additional MARID_JVM options via /etc/opsgenie/profile:

SSL_OPTS="\
-Djavax.net.debug=all \
-Djavax.net.ssl.keyStoreType=pkcs12 \
-Djavax.net.ssl.keyStore=/path/to/keystore/opsgenie.p12 \
-Djavax.net.ssl.keyStorePassword=[removed for github] \
-Djavax.net.ssl.trustStore=/path/to/cacerts \
-Djavax.net.ssl.trustStoreType=jks \
-Djsse.enableSNIExtension=false"

export MARID_JVM="$MARID_JVM $SSL_OPTS"

The ssl debug logs don't show a client certificate being sent and I end up with a peer not authenticated exception message:

17/12/23 20:07:31.881 WARN: Exception occurred while executing script [nagiosActionExecutor.groovy]. Reason: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
org.codehaus.groovy.runtime.InvokerInvocationException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:97)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
        at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:704)
        at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
        at groovy.lang.Script.invokeMethod(Script.java:78)
        at com.ifountain.opsgenie.client.script.GroovyCompiledScriptEngine.doRun(GroovyCompiledScriptEngine.java:21)
        at com.ifountain.opsgenie.client.script.AbstractCompiledScriptEngine.runScript(AbstractCompiledScriptEngine.java:30)
        at com.ifountain.opsgenie.client.script.ScriptManager.runScript(ScriptManager.java:62)
        at com.ifountain.opsgenie.client.marid.alert.AlertActionUtils.executeActionScript(AlertActionUtils.java:43)
        at com.ifountain.opsgenie.client.marid.alert.PubnubAlertActionListener.processMessage(PubnubAlertActionListener.java:162)
        at com.ifountain.opsgenie.client.marid.alert.PubnubAlertActionListener$2$1$1.run(PubnubAlertActionListener.java:98)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
        at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:421)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:437)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
        at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1138)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1076)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1050)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient$OpsgenieHttpClientRetryMechanism.execute(OpsGenieHttpClient.java:391)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient.executeHttpMethod(OpsGenieHttpClient.java:248)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient.post(OpsGenieHttpClient.java:108)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient.post(OpsGenieHttpClient.java:90)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient.post(OpsGenieHttpClient.java:78)
        at com.ifountain.opsgenie.client.http.OpsGenieHttpClient$post.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
        at nagiosActionExecutor.postToNagios(nagiosActionExecutor.groovy:130)
        at nagiosActionExecutor$postToNagios.callCurrent(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
        at nagiosActionExecutor.run(nagiosActionExecutor.groovy:79)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        ... 18 more

I can get other SSL code (like this) to connect to apache with the same jvm options.

It seems like this line might be the source of the issue, since it's passing in null for the key manager array. Or maybe it's the way the groovy scripts are invoked (e.g., not passing the jvm options)?

Sorry if this is posted to the wrong repo or is just a pebkac issue!

Marid does not create issue on Jira

Hi,

I'm testing the integration with JIRA, and I'm getting this message:

18/08/01 19:02:31.615 WARN: [PubnubAlertActionListener]: Could not process message {"params":"{"type":"Jira","alertId":"99999999999999999","customerId":"99999999999","action":"Create","mappedActionV2":{"name":"createIssue","extraField":""},"integrationId":"999999999999","integrationName":"TesteSusane_JIRA","integrationType":"Jira","sendViaMarid":true,"url":"https://xxxxxxxxx.com\",\"username\":\"someuser\",\"password\":\"somepass\",\"alias\":\"99999999999999\",\"projectKey\":\"OP\",\"issueTypeName\":\"Task\",\"summary\":\"TESTE - AGORA VAI HEIN","description":"The alert has no description."}"}Reason: Exception occurred while executing script [jiraActionExecutor.groovy]. Reason: No such property: action for class: jiraActionExecutor

This is my config file:
######################################## JIRA INTEGRATION - ALERT ACTION CONFIGURATION ######################
#actions.Create.script=jiraActionExecutor.groovy
#actions.AddNote.script=jiraActionExecutor.groovy
#actions.Acknowledge.script=jiraActionExecutor.groovy
#actions.Close.script=jiraActionExecutor.groovy
#actions.Delete.script=jiraActionExecutor.groovy
mappedActions.createIssue.script=jiraActionExecutor.groovy
mappedActions.resolveIssue.script=jiraActionExecutor.groovy
mappedActions.closeIssue.script=jiraActionExecutor.groovy
mappedActions.issueDone.script=jiraActionExecutor.groovy
mappedActions.inProgressIssue.script=jiraActionExecutor.groovy

Can someone help me please?

Thanks!

icinga2 : missing UnAcknowledge callback action

Hello,
UnAcknowledge callback action have been added some year ago for icinga1 && nagios

1acf234#diff-f3d784d6a4b20d73c2c661adda2a2866

It's seem that icinga2 is not implemented

I have tried to add
actions.UnAcknowledge.script=icingaActionExecutor.groovy

and I have this error

19/08/27 10:48:11.059 WARN: [UnAcknowledge]: Will execute action for alertId 6fc8b20b-4404-480b-9144-b202e4f6e528-1566893890551
19/08/27 10:48:12.459 WARN: [UnAcknowledge]: Could not execute at Icinga. Icinga Response:{"error":404.0,"status":"The requested path '' could not be found or the request method is not valid for this path."}

opsgenie-lamp mac bad CPU type in executable

zsh: bad CPU type in executable: ./opsgenie-lamp

MacOS Catalina dropped support for 32bit support. I think this needs to be rebuilt for 64bit.

file reports:
opsgenie-lamp: Mach-O executable i386

Thanks

uuid doesn't exist on Windows minions

The "UUID" grain does not exist by default on windows minions, causing the modules to fail with a UUID error.

I suggest removing the below code, or setting a default uuid if no grain exists:

data['uuid'] = grains['uuid']

below is exception thrown by the module when run on a windows host with no uuid set:

      ID: create_alert_in_opsgenie
Function: module.run
    Name: opsgenie.post_data
  Result: False
 Comment: Module function opsgenie.post_data threw an exception. Exception: 'uuid'
 Started: 17:20:16.966727
Duration: 15.6 ms
 Changes:   

Datadog Warning to Critical does not update title in Opsgenie

When an alert is in a WARNING state and it's notified to OpsGenie, and then it goes from WARNING to CRITICAL in Datadog, the title is not updated in OpsGenie.

Current behavior

Check enters a WARNING state in Datadog
Datadog notifies OpsGenie
OpsGenie creates a new alert
OpsGenie notifies the appropriate users
The Datadog check goes from WARNING to CRITICAL
Datadog notifies of the status change to OpsGenie
OpsGenie handles the Datadog notification as a repetition of the previous one and increases the count

Expected behavior

Check enters a WARNING state in Datadog
Datadog notifies OpsGenie
OpsGenie creates a new alert
OpsGenie notifies the appropriate users
The Datadog check goes from WARNING to CRITICAL
Datadog notifies of the status change to OpsGenie
OpsGenie updates the alert with the new status (CRITICAL) and change the title to the new title send by Datadog. So now it shows Critical/Triggered instead of Warn on as the title.
OpsGenie notifies the appropriate users of the status change

Because it doesn't change the title, my coligues think it's still just a warning.

Icinga2 Integration: Wrongly reporting error attaching details.

In the current debian package (2.14.1), the script icingaActionExecutor.groovy reports the wrong status when attaching metrics to an opsgenie alert.
The Log reports

18/01/08 10:10:21.425 ERROR: Could not attach details details_2018_01_08_10_10_20.zip

The script checks in Line 154 for the existence of response.success which is not available. The response object contains:

data:
  id:1234567890123456789, 
  name:null, 
requestId: "<REQUESTID>", 
result: "Attachment [details_2018_01_08_10_10_20.zip] successfully added to alert [<ALERTID>].",
took: 0.16300000250339508

The current Version in master seems to contain the same issue.

Is it possible to update an alert in OpsGenie when it changes the state in Icinga?

When an alert is in a WARNING state and it's notified to OpsGenie, and then it goes from WARNING to CRITICAL in icinga, the status is not updated in OpsGenie and users are not notified of the status change. Is there a way we can achieve this?

Current behavior

  1. Check enters a WARNING state in Icinga
  2. Icinga notifies OpsGenie
  3. OpsGenie creates a new alert
  4. OpsGenie notifies the appropriate users
  5. The Icinga check goes from WARNING to CRITICAL
  6. Icinga notifies of the status change to OpsGenie
  7. OpsGenie handles the Icinga notification as a repetition of the previous one and increases the count

Expected behavior

  1. Check enters a WARNING state in Icinga
  2. Icinga notifies OpsGenie
  3. OpsGenie creates a new alert
  4. OpsGenie notifies the appropriate users
  5. The Icinga check goes from WARNING to CRITICAL
  6. Icinga notifies of the status change to OpsGenie
  7. OpsGenie updates the alert with the new status (CRITICAL)
  8. OpsGenie notifies the appropriate users of the status change

default zabbix Opsgenie implementation is faulty

I have noticed that by default, this implementation is a bit faulty.
/etc/opsgenie/zabbix2opsgenie -triggerName='zabbix test alert' -triggerStatus='PROBLEM'

The default GO script does not include the 'messages' field that must be passed to the API, so it won't work. Solution is to add a message field to the parameters[]{}.

Also, an alias should be passed to the API if the field is configured in the implementation. You may risk triggering Opsgenie deduplication. You can generate a guuid and pass it as the alias parameter to the API (remember to configure the implementation with the alias field set to {{alias}}.

Exception Type: System.Net.WebException Exception Message: The request was aborted: Could not create SSL/TLS secure channel.

When running the script as is (with changing the URL) you probably will receive an error because Powershell will default use TLS 1.0:

Exception Type: System.Net.WebException Exception Message: The request was aborted: Could not create SSL/TLS secure channel.

Solution:
Add the following to the Powershell script:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Debian packages contain multiple lintian errors and warnings

When running lintian on one of the provided integration packages it gives back quite some errors and warnings. Most of them are easy to fix. Please look into this, thanks in advance.

$ lintian -i opsgenie-icinga_2.19.2_all.deb 
E: opsgenie-icinga: arch-independent-package-contains-binary-or-object usr/bin/icinga2opsgenie
N: 
N:    The package contains a binary or object file but is tagged Architecture:
N:    all.
N:    
N:    If this package contains binaries or objects for cross-compiling or
N:    binary blobs for other purposes independent of the host architecture
N:    (such as BIOS updates or firmware), please add a Lintian override.
N:    
N:    Severity: serious, Certainty: possible
N:    
N:    Check: binaries, Type: binary, udeb
N: 
E: opsgenie-icinga: unstripped-binary-or-object usr/bin/icinga2opsgenie
N: 
N:    The package installs an unstripped binary or object file.
N:    
N:    Please note, that shared libraries have to be stripped with the
N:    --strip-unneeded option.
N:    
N:    Refer to Debian Policy Manual section 10.1 (Binaries) and Debian Policy
N:    Manual section 10.2 (Libraries) for details.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: binaries, Type: binary, udeb
N: 
E: opsgenie-icinga: statically-linked-binary usr/bin/icinga2opsgenie
N: 
N:    The package installs a statically linked binary or object file.
N:    
N:    Usually this is a bug. Otherwise, please add an override if your package
N:    is an exception. Binaries named *-static and *.static are automatically
N:    excluded, as are any binaries in packages named *-static.
N:    
N:    Severity: important, Certainty: possible
N:    
N:    Check: binaries, Type: binary, udeb
N: 
E: opsgenie-icinga: changelog-file-missing-in-native-package
N: 
N:    Each Debian package (which provides a /usr/share/doc/<pkg> directory)
N:    has to install a changelog file. Since this package seems to be a native
N:    Debian package (i.e., there is no upstream source), the file should
N:    usually be installed as /usr/share/doc/<pkg>/changelog.gz
N:    
N:    Note that Lintian may emit this tag if the changelog exists, but it does
N:    not look like a Debian changelog.
N:    
N:    Refer to Debian Policy Manual section 12.7 (Changelog files) for
N:    details.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: changelog-file, Type: binary
N: 
E: opsgenie-icinga: non-etc-file-marked-as-conffile var/opsgenie/marid/scripts/Acknowledge.groovy
N: 
N:    A file installed in some other directory than /etc is marked as
N:    conffile. A conffile typically implies a configuration file, and Policy
N:    mandates such files to be in /etc.
N:    
N:    Refer to Debian Policy Manual section 10.7.2 (Location) for details.
N:    
N:    Severity: serious, Certainty: possible
N:    
N:    Check: conffiles, Type: binary
N: 
E: opsgenie-icinga: non-etc-file-marked-as-conffile var/opsgenie/marid/scripts/AddNote.groovy
E: opsgenie-icinga: non-etc-file-marked-as-conffile var/opsgenie/marid/scripts/AddRecipient.groovy
E: opsgenie-icinga: non-etc-file-marked-as-conffile ... use --no-tag-display-limit to see all (or pipe to a file/program)
E: opsgenie-icinga: file-in-etc-not-marked-as-conffile etc/init.d/marid
N: 
N:    Files in /etc must be marked conffiles if they are included in a
N:    package. Otherwise they should be created by maintainer scripts.
N:    
N:    Refer to Debian Policy Manual section 10.7 (Configuration files) for
N:    details.
N:    
N:    Severity: serious, Certainty: certain
N:    
N:    Check: conffiles, Type: binary
N: 
E: opsgenie-icinga: file-in-etc-not-marked-as-conffile etc/opsgenie/icinga2opsgenie.go
E: opsgenie-icinga: file-in-etc-not-marked-as-conffile etc/opsgenie/marid/.keystore
E: opsgenie-icinga: file-in-etc-not-marked-as-conffile ... use --no-tag-display-limit to see all (or pipe to a file/program)
E: opsgenie-icinga: no-copyright-file
N: 
N:    Each binary package has to include a plain file
N:    /usr/share/doc/<pkg>/copyright
N:    
N:    Refer to Debian Policy Manual section 12.5 (Copyright information) for
N:    details.
N:    
N:    Severity: serious, Certainty: certain
N:    
N:    Check: copyright-file, Type: binary
N: 
E: opsgenie-icinga: extended-description-is-empty
N: 
N:    The extended description (the lines after the first line of the
N:    "Description:" field) is empty.
N:    
N:    Refer to Debian Policy Manual section 3.4 (The description of a package)
N:    for details.
N:    
N:    Severity: serious, Certainty: certain
N:    
N:    Check: description, Type: binary, udeb
N: 
E: opsgenie-icinga: maintainer-address-missing OpsGenie
N: 
N:    The maintainer field must contain the package maintainer's name and
N:    email address, with the name followed by the address inside angle
N:    brackets (< and >). The address seems to be missing.
N:    
N:    Refer to Debian Policy Manual section 5.6.2 (Maintainer) for details.
N:    
N:    Severity: serious, Certainty: certain
N:    
N:    Check: fields, Type: binary, udeb, source
N: 
W: opsgenie-icinga: unknown-section default
N: 
N:    The "Section:" field in this package's control file is not one of the
N:    sections in use on the ftp archive. Valid sections are currently admin,
N:    comm, cli-mono, database, debug, devel, doc, editors, electronics,
N:    embedded, fonts, games, gnome, gnu-r, gnustep, graphics, hamradio,
N:    haskell, httpd, interpreters, java, kde, libdevel, libs, lisp,
N:    localization, kernel, mail, math, misc, net, news, ocaml, oldlibs,
N:    otherosfs, perl, php, python, ruby, science, shells, sound, tex, text,
N:    utils, vcs, video, web, x11, xfce, zope.
N:    
N:    The section name should be preceded by "non-free/" if the package is in
N:    the non-free archive area, and by "contrib/" if the package is in the
N:    contrib archive area.
N:    
N:    Refer to Debian Policy Manual section 2.4 (Sections) for details.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: fields, Type: binary, udeb, source
N: 
E: opsgenie-icinga: non-standard-file-permissions-for-etc-init.d-script etc/init.d/marid 0644 != 0755
N: 
N:    Usually, scripts in the /etc/init.d directory should have mode 0755.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: files, Type: binary, udeb
N: 
E: opsgenie-icinga: non-standard-dir-in-var var/opsgenie/
N: 
N:    The FHS says "Applications should generally not add directories to the
N:    top level of /var. Such directories should only be added if they have
N:    some system-wide implication, and in consultation with the FHS mailing
N:    list."
N:    
N:    Refer to Filesystem Hierarchy Standard (The /var Hierarchy) for details.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: files, Type: binary, udeb
N: 
W: opsgenie-icinga: file-in-unusual-dir var/opsgenie/marid/scripts/Acknowledge.groovy
N: 
N:    This file or symbolic link is in a directory where files are not
N:    normally installed by Debian packages.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: files, Type: binary, udeb
N: 
W: opsgenie-icinga: file-in-unusual-dir var/opsgenie/marid/scripts/AddNote.groovy
W: opsgenie-icinga: file-in-unusual-dir var/opsgenie/marid/scripts/AddRecipient.groovy
W: opsgenie-icinga: file-in-unusual-dir ... use --no-tag-display-limit to see all (or pipe to a file/program)
W: opsgenie-icinga: script-in-etc-init.d-not-registered-via-update-rc.d etc/init.d/marid
N: 
N:    The package installs an /etc/init.d script which is not registered in
N:    the postinst script. This is usually a bug (such as omitting the
N:    #DEBHELPER# token) unless you omit the links intentionally for some
N:    reason or create the links some other way.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: init.d, Type: binary
N: 
E: opsgenie-icinga: init.d-script-does-not-implement-required-option etc/init.d/marid force-reload
N: 
N:    The /etc/init.d scripts have to support the following command line
N:    arguments: start, stop, restart, force-reload.
N:    
N:    Refer to Debian Policy Manual section 9.3.2 (Writing the scripts) for
N:    details.
N:    
N:    Severity: important, Certainty: certain
N:    
N:    Check: init.d, Type: binary
N: 
W: opsgenie-icinga: jar-not-in-usr-share var/lib/opsgenie/marid/aopalliance-repackaged-2.5.0-b32.jar
N: 
N:    The classpath listed in some of the files references files outside of
N:    /usr/share, while all installed JAR files must be within /usr/share/java
N:    for libraries or /usr/share/<package> for JARs for private use.
N:    
N:    The rationale is that jar files are in almost all cases architecture
N:    independent and therefore should be in /usr/share. If the jar file is
N:    truly architecture dependent or it cannot be moved since symlinked jar
N:    files are not accepted by the application, then please override this
N:    tag.
N:    
N:    Refer to Debian policy for Java section 2.2 (Building Java packages) and
N:    Debian policy for Java section 2.3 (Java programs) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: java, Type: binary
N: 
W: opsgenie-icinga: jar-not-in-usr-share var/lib/opsgenie/marid/async-http-client-1.7.1.jar
W: opsgenie-icinga: jar-not-in-usr-share var/lib/opsgenie/marid/bsf-2.4.0.jar
W: opsgenie-icinga: jar-not-in-usr-share ... use --no-tag-display-limit to see all (or pipe to a file/program)
W: opsgenie-icinga: codeless-jar var/lib/opsgenie/marid/org.apache.commons.lang-2.6.jar
N: 
N:    The jar file contains a manifest but no code. This probably indicates
N:    that something went wrong at build-time.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: java, Type: binary
N: 
W: opsgenie-icinga: binary-without-manpage usr/bin/icinga2opsgenie
N: 
N:    Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N:    have a manual page
N:    
N:    Note that though the man program has the capability to check for several
N:    program names in the NAMES section, each of these programs should have
N:    its own manual page (a symbolic link to the appropriate manual page is
N:    sufficient) because other manual page viewers such as xman or tkman
N:    don't support this.
N:    
N:    If the name of the man page differs from the binary by case, man may be
N:    able to find it anyway; however, it is still best practice to make the
N:    case of the man page match the case of the binary.
N:    
N:    If the man pages are provided by another package on which this package
N:    depends, lintian may not be able to determine that man pages are
N:    available. In this case, after confirming that all binaries do have man
N:    pages after this package and its dependencies are installed, please add
N:    a lintian override.
N:    
N:    Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: manpages, Type: binary
N: 
W: opsgenie-icinga: script-not-executable etc/init.d/marid
N: 
N:    This file starts with the #! sequence that marks interpreted scripts,
N:    but it is not executable.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: scripts, Type: binary
N: 
W: opsgenie-icinga: possibly-insecure-handling-of-tmp-files-in-maintainer-script postinst:30
N: 
N:    The maintainer script seems to access a file in /tmp or some other
N:    temporary directory. Since creating temporary files in a world-writable
N:    directory is very dangerous, this is likely to be a security bug. Use
N:    the tempfile or mktemp utilities to create temporary files in these
N:    directories.
N:    
N:    Refer to Debian Policy Manual section 10.4 (Scripts) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: scripts, Type: binary
N: 
W: opsgenie-icinga: maintainer-script-ignores-errors postinst
N: 
N:    The maintainer script doesn't seem to set the -e flag which ensures that
N:    the script's execution is aborted when any executed command fails.
N:    
N:    Refer to Debian Policy Manual section 10.4 (Scripts) for details.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: scripts, Type: binary
N: 
W: opsgenie-icinga: maintainer-script-ignores-errors preinst

netcool webhook url

Hello,

Can i know do we have webhook url for netcool to connect it from other applications?

if so can you please provide us the url ?

Integration limitations

Find out some issues with integration:

  • Integration doesn't utilize Media Types Zabbix feature. For example, PagerDuty's integration does: https://www.pagerduty.com/docs/guides/zabbix-3-integration-guide/. So one integration installation can send alerts to only one OpsGenie's configured integration.
  • Details of alert should be passed to sending script using event's body, not command's parameters. Current integration will fail to send alert, for example, if trigger name contain asterisk or parentheses.
  • Integration lacks guaranteed delivery, compared to PagerDuty's. Sending alert during short network outage will come to skipping alert, it will never delivered to OpsGenie, that is not acceptable in any serious project.

Hope these issues can be fixed some time. Thanks!

Opsgenie Check_Mk integration not working

I followed the below document to integrate Opsgenie with checkMk. https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-checkmk/
I downloaded the plugin and put the plugin under /omd/sites/[site name]/local/share/check_mk/notifications/
Changed the first line to #!/usr/bin/env python as per #24
The relevant logs from /var/log/notify.log

2022-05-26 08:36:36 Got raw notification (xxxxxxxxxxxx) context with 71 variables
2022-05-26 08:36:36 Global rule 'Opsgenie'...
2022-05-26 08:36:36  -> matches!
2022-05-26 08:36:36    - adding notification of <xxxxxxx> via opsgenie

2022-05-26 08:36:36   * notifying <xxxxxxx>  via opsgenie, parameters: https://api.eu.opsgenie.com/v1/json/checkmk?apiKey=<xxxxxxxxxxxxxx>, bulk: no
2022-05-26 08:36:36 Creating spoolfile: /omd/sites/xxxxxx/var/check_mk/notify/spool/6aa3bdef-xxxxxxxxxxxxxxxxxx

2022-05-26 08:36:40 Got spool file 6aa3bdef (xxxxxxxxxxxxxxxxxxx) for local delivery via opsgenie
2022-05-26 08:36:40      executing /omd/sites/xxxxx/local/share/check_mk/notifications/opsgenie

Can someone help me to identify the issue?

new rpm moves opsgenie-integration.conf

The postinstall script from opsgenie-nagios-2.1.0-1.all.noarch.rpm moves opsgenie-integration.conf to opsgenie-integration.conf.rpmsave and installs its default config.

I think the config file should be declared with %config(noreplace) otherwise package upgrade breaks existing integration.

Opsgenie Check_Mk integration

Hi,

Tried doing everything by the book. Check_Mk is installed using OMD. When I add the opsgenie notification plugin I get the following in the log:

2018-03-20 13:54:27 * notifying opsgenie via opsgenie, parameters: https://api.opsgenie.com/v1/json/checkmk?apiKey={{api-key-removed}}, bulk: no
2018-03-20 13:54:27 executing /omd/sites/prod/share/check_mk/notifications/opsgenie
2018-03-20 13:54:27 Output: Could not find platform independent libraries
2018-03-20 13:54:27 Output: Could not find platform dependent libraries <exec_prefix>
2018-03-20 13:54:27 Output: Consider setting $PYTHONHOME to [:<exec_prefix>]
2018-03-20 13:54:27 Output: Traceback (most recent call last):
2018-03-20 13:54:27 Output: File "/omd/sites/prod/lib/python/site.py", line 73, in
2018-03-20 13:54:27 Output: __boot()
2018-03-20 13:54:27 Output: File "/omd/sites/prod/lib/python/site.py", line 3, in __boot
2018-03-20 13:54:27 Output: import os
2018-03-20 13:54:27 Output: ImportError: No module named os
2018-03-20 13:54:27 Plugin exited with code 1

Can you please assist if I can do anything in regards to this error?

nagios2opsgenie rpm is marked noarch, but contains x86_64 specific binary

The nagios integration RPM published as linked from the Documentation is a file named opsgenie-nagios-2.21.0-1.all.noarch.rpm.

However inside of this package is an x86_64 compiled file.

Rebuilding the go binary for i386 support is trivial:

$ go get github.com/alexcesaro/log/golog
$ GOARCH=386 go build nagios2opsgenie.go
$ file nagios2opsgenie                                                                                                               
nagios2opsgenie: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, with debug_info, not stripped

But your package should be named appropriately as x86_64 specific.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.