Marvel was working until now. For some unknown reason, we get the following error message:
Marvel: Error 400 Bad Request: Cannot set property 'status' of
undefined
There is nothing helpful in the Elasticsearch logs. Our cluster health is green and we have enough disk and memory space on our servers.
I believe you're having a problem with your template. Are you defining by any chance?
template="*"
Delete it and you should be fine.
Related
Update- The issue is fixed
After increasing the memory limit from index.php, the issue is fixed.
Uncaught TypeError: Argument 1 passed to Illuminate\Container\Container::setInstance() must be an instance of Illuminate\Contracts\Container\Container or null, instance of Illuminate\Foundation\Application given and it works again after restart php7.3-fpm
I'm trying to understand why after deployment my server is returning 500 - Internal server error for a simple GET request that checks the server's status which is supposed to return 200 (when I run it locally with unit tests I wrote, it works fine). I retrieved the failed request log, but can't quite seem to understand what the problem is.
In several events the severity column shows: Failed To Complete
The Request summary shows:
These are the Errors and Warnings shown:
Does anyone know why I might be getting theses errors, or why I might be getting a 500 Internal Server error response?
I will add that I already have a GET request that is working:
https://myalertsserver.cloudapp.net/providers/management/alerts which returns 200.
and when I try:
https://myalertsserver.cloudapp.net/providers/status I get a 404 Error.
It seems to me like it has to do with something in the configuration, but I can't seem to understand what.
Thanks in advance.
I am trying to change discover:sampleSize 500 to 1000 but I am getting an error Unable to update UI setting with superuser.
This answer might help you:
https://discuss.elastic.co/t/unable-to-update-ui-setting-request-failed-with-status-code-403/201409
Your user role might be missing access to the ".kibana" index.
When trying to create visualizations with Timelion, I keep getting this error message: [timelion_vis] > Error: in cell #1: [search_phase_execution_exception]
It is the full message, there is no more information provided.
I recently did a project about Access Log Analytics using the ELK-Stack. I set up Logstash and fed our Apache Access Logs to Elasticsearch and in Kibana I created a handful of visualizations. Timelion was especially helpful, I have a bunch of queries that work perfectly - in Kibana 5.2, the version I was required to use for the project.
Now we have it all set up on a live server using the current versions (7.3) of Logstash, Elasticsearch and Kibana. I made adjustments to my visualizations to accomodate the current versions, however I have problems setting up Timelion.
We can't find any more help in the logs either, there is just nothing there. No hint as to what might be wrong.?
Even with .es(*) I get the error. Using my old queries I get the same error, I checked my syntax, it is fine.
However if I type .es(index=logstash-*, timefield='#timestamp', metric='avg:size') I get a result.
The size-field holds a numeric value. all my other queries refer to fields with string-values. So there seems to be problem with that, I just cannot get behind it.
Any ideas? Has anyone else encountered this error before?
This is what comes up in the Kibana Logs:
Error: in cell #1: [search_phase_execution_exception] : Error: in cell #1: [search_phase_execution_exception]
at throwWithCell (/usr/share/kibana/src/legacy/core_plugins/timelion/server/handlers/chain_runner.js:54:11)
at /usr/share/kibana/src/legacy/core_plugins/timelion/server/handlers/chain_runner.js:205:13
at arrayEach (/usr/share/kibana/node_modules/lodash/index.js:1315:13)
at Function. (/usr/share/kibana/node_modules/lodash/index.js:3393:13)
at /usr/share/kibana/src/legacy/core_plugins/timelion/server/handlers/chain_runner.js:197:23
at tryCatcher (/usr/share/kibana/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:517:31)
at Promise._settlePromise (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:574:18)
at Promise._settlePromise0 (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:619:10)
at Promise._settlePromises (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:699:18)
at Promise._fulfill (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:643:18)
at SettledPromiseArray.PromiseArray._resolve (/usr/share/kibana/node_modules/bluebird/js/release/promise_array.js:126:19)
at SettledPromiseArray._promiseResolved (/usr/share/kibana/node_modules/bluebird/js/release/settle.js:16:14)
at SettledPromiseArray._promiseRejected (/usr/share/kibana/node_modules/bluebird/js/release/settle.js:32:17)
at Promise._settlePromise (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:581:26)
at Promise._settlePromise0 (/usr/share/kibana/node_modules/bluebird/js/release/promise.js:619:10)
I have a CentOS6 server with nginx / php-fpm running Magento. Everything was fine for months until recently when random Fatal Errors will popup. It happens in Magento's admin, in the store, and everywhere. It doesn't happen often, but it does happen.
Some of the errors it will throw:
Fatal error: Cannot override final method Mage_Core_Model_Abstract::clearInstance()
Fatal error: Class 'Mage_Catalog_Model_Category' not found
Fatal error: Call to a member function setStoreId() on a non-object
Fatal error: Call to a member function getTable() on a non-object
Once the error throws, you can't get past it. The only way workaround is to restart php-fpm.
I've read things about APC causing problems, but I haven't had success trying those solutions.
The server has 2GB of RAM and the phpinfo is located here:
http://already2harvest.com/php.php
Any gurus have any good ideas I can pursue?
I just noticed this question. But I'll respond anyway.
It seems to be APC that's the culprit . I'm experiencing the exact same issue. If I turn off APC, no more errors. But, of course, that means the performance goes back to being terrible.