Comments (5)
Thanks @barrycarey. It's been a while now, but the idea was to not let them bubble up, because you don't want an intermittent failure in recording metrics to blow up your API for users (though I guess you could argue that metrics being broken is a severe problem so that's okay).
If you don't have log_sends
turned on, sender.send_socket = sender.send_message
is a shortcut to subclassing:
>>> sender = graphyte.Sender('localhost')
>>> sender.send('metric', 42)
error sending message b'metric 42 1632375414\n': [Errno 111] Connection refused
>>> sender.send_socket = sender.send_message
>>> sender.send('metric', 42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/ben/h/graphyte/graphyte.py", line 115, in send
self.send_socket(message)
File "/home/ben/h/graphyte/graphyte.py", line 124, in send_message
sock = socket.create_connection((self.host, self.port), self.timeout)
File "/usr/lib/python3.8/socket.py", line 808, in create_connection
raise err
File "/usr/lib/python3.8/socket.py", line 796, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
Maybe we could simply document this? Or what "API" did you have in mind? Something like a raise_errors
argument to Sender()
that defaults to False
?
from graphyte.
I didn't think of reassigning send_socket(). That's certainly an easier solution to sub-classing.
My use case might be a bit niche but I always feel like giving client code the ability choose how to deal with errors is best. In my case I have a pool of metric services I'm sending to. If one of those services fail I need to be able to have logic to determine how to react (cool down, drop from pool, ect).
I like the idea of having na arg to control it. One downside I can see is if using the background thread it would cause the thread to die. That would need to be documented.
If you're okay with using an arg I can put together a PR.
from graphyte.
Thanks. It seems your use case is exactly when I'd advocate creating a subclass. And you'd override send_message
to be the thing that deals with your pool of metric servers and handle appropriately. That would work for interval / background thread mode too.
That said, if you want to go ahead with this, I don't mind adding it, to give the user more control. If you do go ahead and submit a PR, let's call the new parameter raise_send_errors
to be explicit (default False
). We'll need a test for it. Good point regarding what to do in the background thread case. I think probably Sender.__init__
should simply disallow that case and raise a ValueError
if you provide raise_send_errors and interval is not None
.
from graphyte.
I just submitted PR #18 before I realized you responded here.
During init I checked if interval was provided. If it was and raise_send_errors it true, it logs a message and sets raise_send_errors to false. I can modify to throw in exception if that's what you prefer.
from graphyte.
Merged your PR, thanks!
from graphyte.
Related Issues (11)
- Add support for sending data in pickle format HOT 2
- installing in windows causing error HOT 2
- rounding timestamp will loose some data HOT 1
- Data not getting added when given past datetime, but works for datetime of today. HOT 2
- Sending large number of messages via async method causes loss of data HOT 3
- Exceptions should be thrown for the upper level to handle. HOT 1
- Queued messages should not get lost on exception during sending HOT 3
- Batch and interval arguments are confusing HOT 2
- add support for a statsd styled message HOT 3
- distutils is deprecated in Python 3.10 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphyte.