Added Cassandra configuration Java class in the common project similar
to existing db.
Change-Id: I9aa250bab206438f9b98bd211d472c0d8fe12bde
story: 2001231
task: 5957
Example: avg(some_timer{quantile=0.99}) > 0.1)
Changes:
* add DECIMAL (floating point value) to allowed tokens for dimensions
Without this fix, an alarm-definition like the above one once injected
through the Python API will break the Java-ORM layer because the
alarm-definition cannot be parsed by the generated ANTLR parser.
As a consequence the thresholder worker will terminate, leading to a
crash-cycle. I could not find a way to make the ORM-layer ignore
non-parseable alarm-definitions. So maybe this fix should be
complemented by an extension of the Python API that uses exactly the
same ANTLR grammar to validate incoming alarm-definitions.
Change-Id: Ibbd41e1b817ebadc74b1b4a677db898cfa173ccb
For a last function, the only values that matters is the last
one so always add it to the first window. This avoid the problem
where an OK value may be in a future window but the current window
has an older alarm value.
Change-Id: I20f8e91da266fdb917dd36ded60d1a5c608b74d0
Closes-Bug: #1618641
We had a case where the authorization VIP was reset after the
monasca-api started. The auth connection pool did not try to
reconnect since we did not meet the configured idle time, and
we had to restart the monasca-api. This fix will allow the
monasca-api to reconnect the auth pool connections when we
get an exception.
Change-Id: I7e45970360720193b2d0ba27964bc22f66db79d3
This is required since we have changed NotificationMethodType to
String. This change will cause build error in Monasca-api where
enum.name() is used. Once this merges, that needs to be fixed
Change-Id: I69a0c2ae03d4c02de161b21d78d115e71c798226
Add the LAST function to the Java parser and its associated classes.
It will save the last value received by its timestamp
Update SubAlarmDb to have a state field. This will be used in the
Threshold Engine for the new LAST function
Add a force argument to SubAlarmStats.addValue() because the
Threshold Engine will always need to add the values for the alarm
because they are only sent once
The changes to Java Monasca API and Monasca Thresh for this last-value
will require these changes, first
Also, remove all trailing spaces from AlarmExpression.g4
Change-Id: Ie3192370057676e89bfebbc5ce4243b1a3ecf0ea
Implements: Blueprint last-value
Alarms can be created with deterministic keyword.
'deterministic' can be passed as part of alarm expression using:
* keyword deterministic
If 'deterministic' is not found in expression it is assumed
to be 'false'.
Implements: blueprint alarmsonlogs
Change-Id: Ia42f9a1be37c31416bdac341b092fe527f860c16
Created a new constructor including the new field. We have both
so we can support with or without passing in the period
which will help us with supporting the old API and the new API.
Once the transition occurs with the new API will remove the old
constructor
Change-Id: Idf0db02f51762633db6ccb60eeca2eb780c70e29
Turns out the beginning of the token is largely the same
and not very meaningful in a log. Instead log the end
of the token which should be different between legitimate
tokens.
Change-Id: I805965cc67d75ec975d2d26951fa9396e5397ede
This change comes as a recommendation from our keystone
engineer, not good practice to log full tokens. Also change
this log message:
'monasca.common.middleware.TokenAuth: 401 No token found.'
to debug level to avoid filling the log with these
messages as the result of a load balancer calling HEAD
without a token.
Change-Id: I6a04e98c398e163fb972020be1e580869b2538d7
This was seen in a monasca-api.log:
ERROR [2016-02-13 17:18:41,546] monasca.common.middleware.TokenExceptionHandler:
Http Client Exception java.lang.NumberFormatException:
multiple points com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.NumberFormatException: multiple points
Search shows that this can be caused by using a SimpleDateFormat concurrently
in two or more threads. SimpleDataFormat is not Thread Safe.
Use ThreadLocal to access SimpleDateFormant safely
Change-Id: Id12e8da8acc8b8a36be2504b55a219eef7293d44
- fix prevents situation when decimal
separator for default locale
is set to comma instead of dot.
Change-Id: I667682e4ed5e1d69e23ac2e82922cca024d1c467
- removed unused dependencies
- matched joda to entire monasca
- switched to standard java date + added explicit UTC
Change-Id: I04e986097010792aed772e83e529edb6d88a2125
Mysql jdbc connector returns an Integer when querying period and period.
Drizzle jdbc connector returns a Long. Adding appropriate conversions
that are used by monasca-api and monasca-thresh.
Change-Id: I4282b7de3fcbd82b3196bce1b4379076eff60bbc
add adminUserDomainName and adminProjectDomainName to api-config.yaml
to scope the username or projectname with a domainname
Change-Id: I12e0a1594961ef15eac6e401521d05a15a2014ad
Closes-Bug: #1484594
- refactored code to match java guidelines
- added missed indexes
- fixed invalid string lengths according to latest mon.sql from ansible-monasca-schema
- introduced relations
- using ordinal for enum fields
Change-Id: Ic84bf542c10ff714885c7a53bb9cbe3a2fb728cd
In the default case of a period being 60 and the evalation period being 60, the
window was being alternately slid 0 slots and then 2 slots. This caused it to
reject some recent measurements.
To illustrate what was happening, assume a SlidingWindow with a period of 60, and
a viewEndTimestamp of 60, and the AlarmDelay default of 30 seconds. AlarmDelay is
used to increase the likliehood a metric arrives before the window is evaluated.
Also assume the evaluation period is happening at 20 seconds after every minute.
On the first one, at time 20, the time is not past the viewEndTimeStamp so nothing
happens. On the second one, at time 80, the time is past the viewEndTimeStamp but
the window doesn't slide because the time has be > viewEndTimestamp + alarmDelay.
At time 140, time is > viewEndTimestamp + alarmDelay so the window is slid. However,
since the alarmDelay wasn't being accounted for in the number of slots to slide, it
was sliding it one too far. On the next period it wouldn't slide at all and then
the next one it would do two again.
This was fixed by accounting for alarmDelay when calculating the number of slots to
slide
Change-Id: I4fcfd41f2de515684b3d0054f9c46c925ee4807b
If threshold is very large, for example, 21474836480, it would get
printed using scientific notation. If that expression was then used
to recreate the AlarmSubExpression, it would fail because the parser
didn't handle scientific notation.
So, instead use DecimalFormat to ensure a valid decimal number without
scientific notation. This then limits the threshold to 15 decimal
places, but that should be enough. It would be better to have no limit
but I have not been able to find a way to do that.
Change-Id: I0511bd73a0ab65498dd615d8f5049b5663720b6a
Fixes JAH-1987.
Fixes "API is failing keystone authentication and never recovering".
Make Monasca-API release HTTP connection in finally clause for Keystone
requests.
Change-Id: Ia4c9899a311794cad8f2fa538fce11bcc265a7e2
