I see that buffer-has-markers-at will at least tell if there are markers pointing to a position, but not only has it been marked obsolete since 24.3, it doesn't provide one a means to actually get a marker object.
Looking at the C source, I can see that buffer to buffer_text structs point to a singly linked list of Lisp_marker structs, but I can't find any Elisp functions to access them. Also, there's a related thread from 1999.
To expand on my comment: there is indeed no function that gives you the set of markers present in a buffer.
Part of the reason for that it that while at the implementation-level each buffer holds a list of its markers, at the conceptual level, markers point to buffers but not the other way around: if a marker is not referred to by any data any more, it will be garbage-collected.
So the list of markers you can find in the C source contains "real markers" as well as "zombie markers", i.e. markers which have become unreachable and will be eliminated at the next GC.
Exposing this to Elisp means that some of those zombie markers could be "resuscitated". Maybe it can be done without introducing any technical problems, but it does mean that the semantics of such a function would be a bit ugly.
So I guess it could be OK to provide this as a debugging aid (and make the function call the GC first, so as to strip away the zombies), but it's not clear it would be very useful: some of those markers are purely internal thingies introduced temporarily by the likes of save-excursion.
Maybe a better option is to make your code use (0-length) overlays instead of markers, so you can use overlays-in, and so you can set properties on those overlays, making it much easier to figure out what each of those overlays is for.